Download Checklist

Secure Code Review

The team at Software Secured takes pride in their secure code review abilities. We perform secure code review activities internally on our applications, as well as, on client secure code review and hybrid assessments. We do a lot more of the latter, especially hybrid assessments, which consist of network and web application testing plus secure code review.

From the perspective of our team of penetration testers, secure code review is a vital ally in reporting security findings, it allows us to understand the inner workings of applications, by permitting us to correlate our dynamic testing findings with our static testing findings as well as increasing the automated test coverage we can apply. This is a powerful combination containing both SAST and DAST techniques, each with their individual pros and cons. We employ the two techniques in combination as it is more powerful than each technique performed individually, which allows our team to deliver high quality reports to our clients.

While searching through countless published code review guides and checklists, we found a gap that lacked a focus on quality security testing. With that, we built the following list as a compilation of OWASP code review, strong components of other lists, and added a few of our own.

Below you’ll find the procedure to follow when beginning a secure code review along with the accompanying checklist, which can be downloaded for your use

Secure Code Review Checklist

1.  Download the version of the code to be tested.

2. Look at the file / folder structure.

• We are looking for how the code is layed out, to better understand where to find sensitive files.
• Confirm there is nothing missing

3.  Open the code in an IDE or text editor. The tool should have the following capabilities:

• Open many files quickly.
• Multiple search tabs to refer to old search results.
• Regular expressions.

This allows us to perform searches against the code in a standard way.

4. Search through the code for the following information:

• Configure Files

• These can be used for authentication, authorization, file upload, database access etc. Does the application use Ruby on Rails, or Java Spring.

• Application Routes

• How does user input map to the application.

• Sensitive Keywords

• Password, token, select, update, encode, decode, sanitize, filter.

5. Scan the code with an assortment of static analysis tools. (for example on Java applications we would use SpotBugs with the findsecbugs plugin). I've included a list below that describes scanners we use:

• Java - SpotBugs + FindSecBugs + reshift
  
• Ruby - Brakeman
• Python - Bandit
• .Net - Roslynn Security Guard
• JavaScript - EsLint with Security Rules and Retire.js
• Third Party Dependencies - DependencyCheck

Here is a valuable list of SAST tools that we reference when we require different scanners.

6. Check every result from the scanners that are run against the target code base. Valid security issues are logged into a reporting tool, and invalid issues are crossed off. For each result that the scanner returns we look for the following three key pieces of information:

• Source
• Sink
• Any transformations that occur on the data that flows from source to sink.

The tester will always be able to identify whether a security finding from the scanner is valid by following this format. Once the three pieces of information are known, it becomes straightforward to discern if the issue is valid.

While checking each result, audit the file of other types of issues. Often scanners will incorrectly flag the category of some code. This can also help the tester better understand the application they are testing.

For each issue, question your assumptions as a tester. The code plus the docs are the truth and can be easily searched.

7. Once we find a valid issue, we perform search queries on the code for more issues of the same type. This is done by running regex searches against the code, and usually uncovers copy and pasting of code.crossed off. For each result that the scanner returns we look for the following three key pieces of information:

8. Search for documentation on anything the tester doesn't understand. This helps the tester gain insight into whether the framework/library is being used properly.

A key activity the tester will perform is to take notes of anything they would like to follow up on. Performing a security review is time sensitive and requires the tester to not waste time searching for issues which aren't there. This is solved by taking notes of issues to come back to while reviewing the scanner results, so as to not get stuck on anything. This is done for the entirety of the review and as a way to keep a log of what has been done and checked.

The security code review checklist in combination with the secure code review process described above, culminates in how we at Software Secured approach the subject of secure code review. This approach has delivered many quality issues into the hands of our clients, which has helped them assess their risk and apply appropriate mitigation. By following a strict regimented approach, we maintain and increase the quality of our product, which is delivered to happy clients.

Below is the downloadable checklist which can be used to audit an application for common web vulnerabilities.

Download Checklist

Resources

Examples of Code Review Guides

Value of Combining Sast and Dast

What do SAST, DAST mean to developers? 

DAST: What Are They Good at Finding

Application Security Code Review Introduction

Awesome Static Analysis

OWASP Top Ten 2013 Cheat Sheet