Security Code Review Tips for Application Developers

One of the key aspects of secured application development practice is Security code review. Security code review, as like normal code review, could be done either in automated fashion using one or more tools, or in manual fashion where one or more developers are involved in doing code review. Unlike application normal code review where one needs the knowledge of business functionality and programming language & related technologies’ knowledge, Security code review requires knowledge on different aspects of security including some of the following:

• Common threats (STRIDE can be a great place to start understanding threats)
• Vulnerabilities (OWASP Top 10 describes most common vulnerabilities)
• Remediation techniques recommended in that programming language

To be able to do effective security code review, one may be required to adopt top-down approach where he/she may be required to know the details of use-case and drill down further. Perform some of the following activities while doing security code review:

• Get to know the details on use-case whose code is under review
• Decompose use-case to be represented in form of following:
  1. Actors (external entity)
  2. Data flows
  3. Applications/modules
  4. Data stores

  This kind of decomposition belongs to threat modeling based on data flow diagrams (DFD).

• Identify threats to all of the above elements. STRIDE could be used to identify one or more threats to above elements. STRIDE stands for  Spoofing Identity, Tampering Data, Repudiation, Information Disclosure, Denial of Service and Elevation of Privelege. For example, actors would have threat from Spoofing identity and repudiation.Data flows could have threats from Tampering data, Information disclosure, and Denial of service etc.
• Once threats have been associated with all the elements, examine vulnerabilities which can be exploited for threat to become attacks. For example, SQL injection, session handling, broken authentication and authorization etc. You may want to check the top 10 vulnerabilities suggested by OWASP Top 10.
• Once vulnerabilities have been identified, check whether there are remediation controls in place or not for all these vulnerabilities. These remediation controls are in form of secured coding practices that are there in place. The recommendation on remediation controls can be read on individual pages on OWASP Top 10. Following are some of the recommendation for following threats/vulnerabilities:
  1. SQL Injection: Look for the usage of parametrized API in the query related code. Additionally, also ask whether one or more input validation framework such as OWASP ESAPI is used to escape characters that could introduce injections.
  2. Cross Site Scripting (XSS): Look for the code for escaping all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL). One could check the OWASP XSS Prevention Cheat Sheet for details on the required data escaping techniques.
  3. Sensitive Data Exposure: Ask for the data which are sensitive in nature and check the data storage policy for that data. You may want to check for encryption of data from coding perspective.
  4. Missing Function Level Access Control: While doing code review, check on who all is authorized to access this function and whether proper access control is there in place based on user types. In controller or business logic, at times, there are data sets which need to be accessible to only particular class of users. Check whether there is check for same or not.

Thus, honestly speaking, this would require a minimum level of application security training for the developers to be able to perform effective security code review.

Watch out this space for more.