Manual Code Review : Security Assessment

Secure Code Review is code assessment for identifying security vulnerabilities at an early stage in development lifecycle. When used together with penetration testing(automated and manual), it can significantly improve security posture of an organization. This article does not discuss a process for performing a secure code review but discusses on the mechanics of reviewing code.

How to begin assessment?
Defining a generic checklist can give security reviewers desired context and is a good barometer for level of security checks developers have incorporated. Checklist should cover most critical security controls and vulnerability areas such as :

• Data Validation
• Authentication
• Authorization
• Session Management
• Error Handling
• Cryptography
• Logging
• Security Misconfiguration

It is not possible to cover all areas but here we will discuss some flaws identified during code review and their mitigation techniques to give a perspective on how to approach code review assessment.

What are some factors to be considered for Code Assessment?

1. Review Input Validation mechanism :
   Always validate user data with full knowledge of what your application is trying to accomplish. Types of validation :
   • Data Validation : If possible an exact match validation should be implemented to permits data that conforms to an expected value. Whitelist (a little weaker but more flexible approach) is common that permits characters/regular expressions defined within a whitelist. Other alternative is blacklist of “bad characters” only. This approach would need regular maintenance as more mechanism are devised to bypass this list via new attack payloads.
   • Business Validation : Understanding of business logic is required prior to reviewing code. It could be used to limit value range or a transaction entered by a user and reject input which does not make business sense.

   For validation an analyst must ensure the following :

   • Data Validation mechanism is present.
   • Proper length checks on all input exist.
   • All fields, cookies, http headers/bodies, and form fields are validated.
   • Validation occurs on the server side.
2. Review commented code :
   A reviewer should ensure that all commented code containing sensitive information are removed before an application is rolled out into a production environment.
3. Review Error handling mechanism :
   The purpose of reviewing the Error Handling mechanism is to ensure that application handles exception gracefully and no sensitive information is presented to the user.
4. Review security-related HTTP headers :
   HTTP response headers are used to increase the security of application and restricts modern browsers from running into easily preventable bugs. This offers significantly faster and cheaper method for partial mitigation of existing issues and act as an additional layer of defense for new applications. Some of the common headers an analyst can ensure are :

   Header Name	Example
   Strict-Transport-Security	Strict-Transport-Security : max-age=16070400; includeSubDomains
   X-Frame-Options	X-Frame-Options : deny
   X-XSS-Protection	X-XSS-Protection: 1; mode=block
   Content-Security-PolicyContent-Security-Policy, X-Content-Security-policy, X-WebKit-CSP,	Content-Security-Policy: default-src ‘self’

5. Review cookies :
   Cookies are often a key vector for malicious user so a reviewer must take a look at what attributes are set for a cookie and test if they are secure. Some of the attributes to be reviewed are :

   Attribute	Reason
   Secure	Cookie containing sensitive information is transmitted over an encrypted connection.
   HttpOnly	Cookie cannot be accessed by client-side APIs such as JavaScript.
   Expires	Signifies how long the browser should use the cookie and when to delete.