Security Code Review 101

How to ensure secure coding practices when doing code review

Code review is, hopefully, part of regular development practices for any organization. Adding security elements to code review is the most effective measure in preventing vulnerabilities, even before the first commit.

This series of short articles is a primer that includes the basic elements to get you started. We will review several software examples in order to figure out the good from the ugly.

The Biggest Security Issues

OWASP Top 10 and MITRE Top 25 include lists of common programming flaws that lead to vulnerabilities and exploits in software. These lists are reviewed periodically by industry experts and are included in compliance standards such as PCI-DSS.

Our security code review examples will focus on the following OWASP Top 10 and MITRE Top 25 entries:

  • Injection
  • Memory Flaws
  • Sensitive Data Exposure
  • Cross-Site Scripting
  • Broken Access Control.

The Basic Secure Coding Practices

One of the goals of regular code review is to spot missing best practices. Security code review is about identifying the missing secure coding practices. These practices are also known as software defences or in Threat Modeling terms countermeasures. There are many types of software defences but some are more important and effective than others.

The short list below is based on the number of security flaws that each defence prevents as well as the severity of the flaws based on OWASP Top 10 and MITRE Top 25 industry classifications.

  • Input Validation, prevents a wide range of attacks such as Injection, Cross-Site Scripting and Path Manipulation.
  • Parameterized Statements, prevent Injection attacks when Input Validation cannot be employed. Injection is #1 in the OWASP Top 10.
  • Memory Safe Functions and Safe Memory Management practices prevent memory flaws such as Buffer Overflow which is at #3 in the Mitre Top 25 immediately after SQL Injection and OS Command Injection.
  • Data Encryption in transit and at rest prevents data breaches which are covered at #3 in the OWASP Top 10 category Sensitive Data Exposure.
  • Neutralizing Output prevents Cross-Site Scripting flaws which plague web applications and should be the primary concern for front-end developers.
  • Indirect Object References prevent dangerous flaws associated with file management such as Path Traversal a vulnerability in the Broken Access Control OWASP Top 10 category.

There are many threat categories and best practices that will not be discussed in this series. It is important to realize security code review is not a replacement for other application security controls such as static analysis or penetration testing.

Security code review is also only a small part of the code review process. It should not take too long. As such we must prioritize the things we are looking for to get the most bang for the buck.

In addition many threat categories are handled in the application framework as opposed to every day code changes. For example, #2 in OWASP Top 10 is Broken Authentication. It is not likely that you will deal with this category often during code review because authentication is usually handled by the framework.

The articles will contain examples from Java, C/C++ and JavaScript programming languages. However the concepts can be easily transferred to other languages. Input Validation in Java is similar to input validation in Python and PHP.

In next article in this series we will review in detail the concept of Input Validation.

Click the following link to access the next article in the series: https://medium.com/@paul_io/security-code-review-101-input-validation-f309b1be96c7