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.
Sensitive Data Exposure
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.
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 practicesprevent 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.
In next article in this series we will review in detail the concept of Input Validation.