Skip to content

Code Audit: Code review

Code review is an effective technique for identifying security flaws. Together with automated testing, code review can help identify, and prevent security flaws.

We should all be familiar with the concept of code review. Its part of the Agile development cycle (as well as other SDLC).

This style of Code review is designed to help keep our code "maintainable", rather than it becoming an unholy mess of competing standards.

In a traditional code review we step through the code and ask questions like:

  1. Do we follow software development best practice (i.e. OO principles)
  2. Does the software meet the functional requirements.
  3. De we meet style and formatting guidelines (i.e. PEP8)
  4. Relevant Comment's etc
  5. Are there Unit Tests?

Security Based Code Review

In a secure code review, we audit the source code for an application to verify that the proper security controls are present, they work as intended and have been used in the right places. A thorough code review should result in an application where automated testing (or manual penetration testing) finds no more security related flaws.

While we can use automated tools for some parts of code review, there is still a heavy human element involved. Tools are great at assessing the codebase to identify potential flaws, but these still need to be assessed by a human to check if the flaw is real.

Note

I think of this like unit tests, and UX testing. We can use automated Unit testing to see if things are correct and identify bugs in the code.

However, while we have some heuristics for usability, to get a through test we need humans to check our work.

Working with a Framework and Dependencies

Programs also often make use of a framework, and external APIS. (For example, using Flask for Python Web Applications, or NodeJS libraries)

  • What framework are we using, what characteristics does it have
  • Identifying all libraries used

Once we have identified the framework, and libraries. We can perform an audit to make sure the versions used are up to date, and have no known security flaws.

Identifying Attack Vectors

The first part of our code review is to identify any attack vectors in the application. These occur then an application takes form of input, processes it, and produces some form of output. (Output can include storing the data)

Areas that involve user input can include:

  • User Input in the Browser
  • User Uploaded Files
  • Cookies
  • HTTP Request information
  • Configuration Files
  • External Processes (eg linking to another API)
  • Data Feeds (JSON etc)
  • Command Line Parameters
  • Environment Variables

Code for functions that deal with any form of input data should be reviewed, for potential security flaws.

We will need to ensure that ALL of these items go through an appropriate input validation process. It is appropriate to use Data Flow Modelling to track the flow and processing of data in the application

Note

We can also keep track of where user input is accepted, for use later in automated testing and fuzzing.

We also need to identify functions that are related to security. For Example:

  • Authentication
  • Authorization
  • Session Management
  • Cryptography
  • Data / Input Validation
  • Error Handling
  • Logging / Auditing

Again, a review of the functionally for all security related functions should be performed. Does the function perform as expected, what happens in an error condition etc.

Assessing Threats

If any potential threats are identified, we should document and rate the threat. We should make use of Threat Rating Systems to document the risk levels.

Dealing with specific threats.

We have looked at a generic process for code review. However, due to the number and types of threat we wont go into that much more detail. I will give an example of what we can do when it comes to session managment below.

The OWASP Guide to Code Review Has a comprehensive overview of how to assess and identify specific threats.

Example: Session Management

HTTP is a stateless protocol (it treats every connection independently). To get much of the functionality we expect off a modern website, we need to incorporate session management.

Sessions are used to allow a web server to keep track of a users interaction with the site. This is essential for things like Logging into the site, handling forms, or making other requests.

You can find a tutorial on session generation

Session ID Generation

Session managment is usually done through a session cookie. This links a session ID to a given user.

  • The way the session ID is generated should be Strong, this will make it hard for an attacker to brute force session ID's and masquerade as another user.

  • You should check the Session ID generation method used in the application to make sure there are no known weaknesses.

Session Authorization

  • The application should check that the session is valid before carrying out any tasks that require authorization. Simply put, we should check if the user has been authenticated, and is allowed to perform that task based on the session token
  • Reviewing Code where sessions are created and invalidated (destroyed) is also important. Consider implementing some form of session rotation (Periodically Issue a new session token) to avoid session fixation
  • Sessions should also fail securely. It is better to drop the session and require the user to log back in in the case of an error.

Sessions and the Browser

  • We should transfer session cookies using HTTPS
  • Avoid transferring session data using GET requests (as it means that session tokens may be available in the logs)
  • Check session cookies for secure settings, such as HTTP-Only (stops JavaScript from accessing the session), and secure (stops transfer over HTTP)

Session Lifecycle

  • Sessions should have an inactivity timeout.
  • We should implement an expiry date of sessions. This can avoid session fixation
  • Log out commands should be checked, to ensure they correctly invalidate the session token.

Summary

In this article we had a brief look at the security based code review process.

When to Review? #whentoreview

Now we have established what a security based code review looks like. Our next question is: "When do we do the review?"

  • Do we make it a separate process?
  • Weekly, Monthly ?
  • Can we try to integrate it with our usual code review process?

Share your throughs on the Aula Feed with the tag #whentoreview

Further Reading

OWASP Guide to Code Review

Back to top