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
- Session Management
- Error Handling
- 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?
- 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.
- 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.
- 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.
- 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’
- 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 :
Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.My Personal Notes arrow_drop_up