Source Code Review

Introduction

Source Code review is a process which discovers hidden vulnerabilities, design flaws, and verifies if key security controls are implemented. Code review helps developers learn the code base, as well as help them learn new technologies and techniques that grow their skill sets.

In source code review we are using a combination of scanning tools and manual review to detect insecure coding practices, backdoor, injection flaws, cross site scripting errors, insecure handling of resources, weak cryptography etc.

Many claims that this process is time consuming and too costly, but there is no doubt that this process is the fastest and most accurate way to find and diagnose many problems, mostly your code is the base from hackers are taking advantage. There are dozens of security problems that simply can’t be found any other way. A source code review is also the best way to detect intentional or accidental backdoors and logic bombs in applications that you acquire from third parties or develop in house. Certain security standards (such as OCI DSS) demand that a source code is conducted prior to production usage of software to identify the potential coding vulnerabilities.

Why need to conduct Source Code Review

A code review can reveal issues such as common bugs, thread synchronization, dealing with error conditions, correct accounting for reference-counting and other potential resource leaks, security problems, and ensuring that unit tests cover all code paths, error cases, and limit cases.

• Testing is carried out by application security experts in various application technologies and platforms.
• Following industry best practices and guidelines such as the web application security project (OWASP), the Web Application Security Consortium (WASC) and open source security testing methodology manual (OSSTMM)
• High emphasis on manual verification along with automated tools (open source and commercial) based testing.
• Vulnerability correlation facilitates in verification of automated and manually identified vulnerabilities and eliminating false positive.

Focus of a Secure Code Review

A secure code review focus on 7 security mechanisms. An application that is weak in any area already makes itself a target for a hacker. These 7 security mechanism are:

1. Authentication
2. Authorization
3. Session management
4. Data validation
5. Error handling
6. Logging
7. Encryption

Manual vs. Automated Source Code Review

Manual Code Review Pros:

• In a manual review reviewer read each and every line of the code and analyze it for potential flows.
• Security issues like Authentication, Authorization and session management can be better detect manually.
• Ability to deep dive into the code paths to check for logical errors and flaws in the design.

Manual Code Review Cons:

• Requires an expert of both the languages and the frameworks used in the app as well as a deep knowledge of security.
• Manual testing is not consistent. Different reviewers will produce different reports, resulting in inconsistent findings between reviewers.
• It is time consuming process.

Automated Code Review Pros:

• Automated tools finish a lot faster than manual testing, by orders of magnitude.
• Automated are automatically updated with the newest exploits.
• Depending on tool choice, an automated source code review tool can be customized per organizational needs, especially certain compliance standards and for high-value applications.

Automated Code Review Cons:

• Automated tools cannot test for business logic flaws; they hunt the technical flaws only - and the more common ones, at that.
• On the other hand, automated tools will only get updated once every while, but a human can learn about a spanking new technique and implement it the very next day.
• Automated tools usually include a very high percentage of false positives (from 30% to over 90%, depending on the methodology and choice of product).

Three-Phase Code Analysis

• Phase 1 – Run all available code-analysis tools Multiple tools should be used to offset tool biases and minimize false positives and false negatives Analysts should pay attention to every warning or error – Warnings from multiple tools may indicate that the code that needs closer scrutiny (e.g. manual analysis). Code should be evaluated early, preferable with each build, and re-evaluated at every milestone.
• Phase 2 – Look for common vulnerability patterns – Analysts should make sure that code reviews cover the most common vulnerabilities and weaknesses, such as integer arithmetic issues, buffer overruns, SQL injection, and cross-site scripting (XSS) – Sources for such common vulnerabilities and weaknesses include the Common Vulnerabilities and Exposures (CVE) and Common Weaknesses Enumeration (CWE) databases, maintained by the MITRE Corporation and accessible at: http://cve.mitre.org/cve/ and http://cwe.mitre.org/ – MITRE, in cooperation with the SANS Institute, also maintain a list of the “Top 25 Most Dangerous Programming Errors” (http://cwe.mitre.org/top25/index.html) that can lead to serious vulnerabilities – Static code analysis tool and manual techniques should at a minimum, address these Top 25

• Phase 3 – Dig deep into risky code – Analysts should also use manual analysis (e.g. code inspection) to more thoroughly evaluate any risky code that has been identified based on the attack surface, or based on the heuristics below – Such code review should start at the entry point for each module under review and should trace data flow though the system, evaluating the data, how it’s used, and if security objectives might be compromised.

Tips to better Source Code Review:

• Use Checklist: It´s very likely that each person on your team makes the same 10 mistakes over and over. Omissions in particular are the hardest defects to find because it´s difficult to review something that isn´t there. Checklists are the most effective way to eliminate frequently made errors and to combat the challenges of omission finding.
• Practice lightweight code reviews: To fully optimize your team´s time and to effectively measure its results, a lightweight, tool-assisted process is recommended. According to the study, lightweight code review takes less than 20% the time of formal reviews and finds just as many bugs! Formal, or heavyweight, inspection averages nine hours per 200 LOC (Line of Code). While often effective, this rigid process requires up to six participants and hours of meetings paging through detailed code printouts.
• Highlight issues in the code: Never force software developers to change the code written by them. It may hurt their ego and they may repeat the same mistake if they do not understand the reason behind code change recommendation. Highlight the issues in the existing code and its consequences.
• Do few things offline: Instead of explaining the entire solution to developers during the code review process, simply share the links of relevant websites or encourage them to research on the internet by providing keywords. This action would certainly save the code reviewer’s time and energy. And of course, developers would also like it, since they too need some time to assimilate the proposed solution. 
• Always be patient and relook if required: Sometimes, developers do not accept suggestions/recommendation and keep debating. A code reviewer many not know the exact context and challenges, when the code was written. A code reviewer should understand all the points being made by the developer without losing patience. Furthermore, to make the point crystal clear, a code reviewer can explain the points on a paper or on a whiteboard by comparing the developer’s approach vs. code reviewer’s approach. Every approach has its pros and cons, need to choose the right approach, whichever weighs more after careful evaluation.
• Explain the need for best coding practice: Generally, software developers mention that best coding practices are not followed due to tight project schedules. Developers may feel that it is an acceptable practice. However, code reviewers should educate software developers that as the code size increases or after sometime, the application becomes very difficult to maintain. Moreover, if a client verifies the code then poor quality code may give wrong impression on the team’s/organization’s quality standards. It may also impact awarding new projects or referring an organization to prospective clients.
• Document all code review comments: Document all code review comments in an email, word document, excel, or any standard tool used by the organization. Making a mistake for the first time is acceptable, but it is not a good sign to repeat the same mistake. The code review document helps software developers to cross check the highlighted issues and avoid making similar mistakes in future. Additionally, maintaining a code review document is a mandatory part of the Capability Maturity Model Integration (CMMI) level process.
• Establish a process for fixing defects found: The best way to ensure that defects are fixed is to use a collaborative code review tool that allows reviewers to log bugs, discuss them with the author, and approve changes in the code. Without an automated tool, bugs found in review likely aren´t logged in the team´s usual defect tracking system because they are found before code is released to QA.
• Find vulnerabilities in context of the application: Not only should you pick up real and applicable vulnerabilities in the context of the application – as it decreases the number of issues – but also, you should propose the countermeasures in the report. That makes developers happy and confident. The scanner may flag any issue as High, Medium or Low. It’s your responsibility to give them appropriate ranking based on applications context.
• Train them: Last but not least, train developers about the vulnerabilities in the real world. Give them training, involve them and encourage them to review their codes before production. Tell them how it saves effort and money. If you have a scanning tool that supports plug-ins for IDE, install it at their machines so that they can do proper development and a hand by hand review.

A Sample Illustration:

Consider this example( Owasp WebGoat Project):

String username = “”;

String password = “”;

username = s.getParser().getRawParameter(USERNAME);

password = s.getParser().getRawParameter(PASSWORD);

……………..

………..……

String query = “SELECT * FROM user_system_data WHERE user_name = ‘”

+ username + “‘ and password = ‘” + password + “‘”;

ec.addElement(new StringElement(query));

The inputs from the user are requested through getRawParameter, and assigned to the ‘username’ and ‘password’ variables. Again, they are being used directly in the SQL query without any input validation and also being embedded into the dynamic query. Any malicious user can tamper with this query to run his own arbitrary SQL codes. So if we try to find all the entry points into the codebase (getRawParameter in this case), we may detect injection flaws. Even if we search for SQL queries being used in the code, if we find that they are being used as dynamic queries, they may be a case of a possible SQL injection.

DOCUMENTATION OF RESULTS

If weaknesses are discovered in source code, then they usually need to be documented. The documentation serves as a basis for the correction and addressing of the discoveries.

It is important that the affected parts of code are referenced as exactly as possible. Ideally, the following data points are used:

Data Point	Example
Software Name	abc v 2.0
File Name	Post.php
Function Name	createNewPost()
Code Lines	Lines 23-42

In addition to that, you could retype the entire code block directly so that a check and referencing is made even easier.

Further information concerning the weakness (classification, description, scenario of attack, example of exploit) add additional quality to the report. Ideally, there’s even a suggestion for a countermeasure. And even more ideally, that countermeasure can be expressed in functional code, because then you’re presenting a solution that is as viable as it gets.

Limitations of a Secure Code Review:

A secure code review is not a silver bullet and performing such a review does not mean that every instance of a security flaw will be discovered. Rather it is one of many different types of activities that can help increase the quality of an application and reduce the number vulnerabilities in software, making it more difficult for a malicious user to exploit.

Open Source or Free Tools of This Type (Reference: OWASP Source Code Analysis Tools)

• Brakeman - Brakeman is an open source vulnerability scanner specifically designed for Ruby on Rails applications
• Codesake Dawn - Codesake Dawn is an open source security source code analyzer designed for Sinatra, Padrino for Ruby on Rails applications. It also works on non-web applications written in Ruby
• FindBugs - Find Bugs (including a few security flaws) in Java programs
• FindSecBugs - A security specific plugin for FingBugs that significantly improves FindBug's ability to find security vulnerabilities in Java programs
• Flawfinder Flawfinder - Scans C and C++
• Google CodeSearchDiggity - Uses Google Code Search to identifies vulnerabilities in open source code projects hosted by Google Code, MS CodePlex, SourceForge, Github, and more. The tool comes with over 130 default searches that identify SQL injection, cross-site scripting (XSS), insecure remote and local file includes, hard-coded passwords, and much more. Essentially, Google CodeSearchDiggity provides a source code security analysis of nearly every single open source code project in existence – simultaneously.
• PMD - PMD scans Java source code and looks for potential code problems (this is a code quality tool that does not focus on security issues)
• PreFast (Microsoft) - PREfast is a static analysis tool that identifies defects in C/C++ programs. Last update 2006.
• RIPS - RIPS is a static source code analyzer for vulnerabilities in PHP web applications. Please see notes on the sourceforge.net site.
• SonarQube - Scans source code for more than 20 languages for Bugs, Vulnerabilities, and Code Smells. SonarQube IDE plugins for Eclipse, Visual Studio, and IntelliJ provided by SonarLint.
• VisualCodeGrepper (VCG) - Scans C/C++, C#, VB, PHP, Java, and PL/SQL for security issues and for comments which may indicate defective code. The config files can be used to carry out additional checks for banned functions or functions which commonly cause security issues.
• Xanitizer - Scans Java for security vulnerabilities, mainly via taint analysis. The tool comes with a number of predefined vulnerability detectors which can additionally be extended by the user.

Commercial Tools of This Type (Reference: OWASP Source Code Analysis Tools)

• AppScan Source (IBM)
• BlueClosure BC Detect (BlueClosure)
• bugScout (Buguroo Offensive Security) Latest generation source code analysis tool bugScout detects source code vulnerabilities and makes possible an accurate management of the life cycles due to its easy use.
• Codacy is free for open source projects, and integrates with tools such as Brakeman, Bandit, FindBugs, and a number of others. It offers security patterns for languages such as Python, Ruby, Scala, Java, Javascript and more.
• Contrast from Contrast Security Contrast performs code security without actually doing static analysis. Contrast does Interactive Application Security Testing (IAST), correlating runtime code & data analysis. It provides code level results without actually relying on static analysis.
• Coverity Code Advisor (Synopsys)
• CxSAST (Checkmarx)
• Fortify (HP)
• Julia - SaaS Java static analysis (JuliaSoft)
• KlocWork (KlocWork)
• Kiuwan - SaaS Software Quality & Security Analysis (an Optimyth company)
• Parasoft Test (Parasoft)
• PVS-Studio (PVS-Studio) For C/C++, C#
• Sentinel Source (Whitehat)
• Seeker (Synopsys) Seeker performs code security without actually doing static analysis. Seeker does Interactive Application Security Testing (IAST), correlating runtime code & data analysis with simulated attacks. It provides code level results without actually relying on static analysis.
• Source Patrol (Pentest)
• Veracode Static Analysis (Veracode)