Secure Code Review

Code review
Code review is systematic examination (sometimes referred to as peer review) of computer source
code. It is intended to find mistakes overlooked in software development, improving the overall
quality of software. Reviews are done in various forms such as pair programming, informal
walkthroughs, and formal inspections.

Introduction
Code review is probably the single-most effective technique for identifying security flaws. When
used together with automated tools and manual penetration testing, code review can significantly
increase the cost effectiveness of an application security verification effort.
This guide does not prescribe a process for performing a security code review. Rather, this guide
focuses on the mechanics of reviewing code for certain vulnerabilities, and provides limited
guidance on how the effort should be structured and executed. OWASP intends to develop a more
detailed process in a future version of this guide.
Manual security code review provides insight into the “real risk” associated with insecure code.
This is the single most important value from a manual approach. A human reviewer can understand
the context for certain coding practices, and make a serious risk estimate that accounts for both the
likelihood of attack and the business impact of a breach.
Secure Code Review Checklist
Design
☐ architecture and design documentation is complete
☐ user and role based privileges are documented
☐ site is well partitioned into public and restricted pages
☐ security is layered each layer assumes other layers may have been compromised
☐ security design covers all 8 principles of web security: authentication, authorization,
confidentiality, message integrity, data integrity, availability, non-repudiation
☐ sensitive data has been identified

Information Gathering
• Get a copy of the code
• Manually explore the file structure of the code
• Look for any missing pieces of code
• Check for frameworks / libraries / dependencies
• Check for application routes and their inputs

Configuration
• Sensitive data is not hard-coded in configuration files
• Develop and test code are properly segregated from production
• Dependencies are up to date

Secure Transmission
• Sensitive data is only transmitted over an SSL connection
• Site is partitioned into private and public URLs
• Sensitive data has been secured in memory, storage and transit
• Sensitive data doesn’t leak to non private channels

Authentication and User Management

☐ user credentials are encrypted in the data store
☐ security policies are configurable (not hardcoded)
☐ standard security frameworks are used (instead of custom code)
☐ SSL is used to protect user credentials and authentication tokens
☐ authentication cookies are not persisted
☐ authentication cookies are encrypted
☐ cookie names and paths are used
☐ application handles user management events such as authentication failure, password reset,
password change, account lockout and cancel account
☐ application handles suspicious events such as multiple failed logon attempts, session replay and
attempted access to restricted resources
☐ strong passwords policies are enforced
☐ authentication credentials are not passed by HTTP GET

Authorization
☐ authentication and authorization should be the first logic executed for each request
☐ authorization checks are granular (page and directory level)
☐ deny access to pages and data by default
☐ re-authenticate for requests that have side-effects
☐ ACLs are configured for all files
☐ authorization based on clearly defined roles
☐ authorization works properly and cannot be circumvented by parameter manipulation
☐ authorization cannot be bypassed by cookie manipulation

Data Validation
• All user input is validated for proper type, length, format and range
• Validation on user input is done server side
• Uploaded files are validated for content type, size, file type and filename
• Special characters are sanitized before being used in external systems, like databases
• Does invalid input trigger handled exceptions

Application Output
• All page output is properly encoded
• All header output is URL encoded
• Cache headers are properly set on sensitive data
• Security headers are properly set on the application
• Sensitive Application information is not revealed to the user
• Error messages don’t reveal sensitive information
• Error messages aren't user controllable

Session Management
☐ no session parameters passed in URLs
☐ session cookies expire in a reasonably short time
☐ session cookies are encrypted
☐ session data is being validated
☐ private data in cookies is kept to a minimum
☐ application avoids excessive cookie use
☐ session id is complex
☐ session storage is secure
☐ application properly handles invalid session ids
☐ session limits such as inactivity timeout are enforced
☐ logout invalids the session
☐ session resources are released when session invalidated
Input Validation
☐ all external input is validated without exception
☐ where possible input is restricted to known good chars
☐ data is validated server side (security should not rely on client-side validations)
☐ application validates numerical input and rejects unexpected input
☐ application efficiently evaluates input length
☐ strong separation between data and commands
☐ strong separation between data and client side scripts
☐ data should be checked for special characters before being passed to SQL, LDAP, OS and third
party commands
☐ http headers are validated for each request (e.g. referrer)

Cryptography
☐ sensitive data has been secured in memory, storage and transit
☐ restricted areas require SSL
☐ sensitive information not passed to/from non-SSL pages
☐ proper SSL set up
☐ SSL provider supports only strong algorithms
☐ web based admin tools require SSL
☐ decryption services protected by authentication/authorisation
☐ require SSL for login page
☐ securely store cryptographic keys

Exception Handling
☐ when exceptions occur the application fails securely
☐ error messages do not reveal sensitive information
☐ system errors are never shown to users
☐ resources are released and transactions rolled back when there is an error

Auditing and Logging

☐ all user / system actions are logged
☐ sensitive information is not logged (e.g. passwords)
☐ logging for user management events (e.g. password reset)
☐ unusual activity such as multiple login attempts are logged
☐ logs have enough detail to reconstruct events for audit purposes
☐ logging is highly configurable (logging levels)
 General
☐ proper configuration of frameworks such as Spring, Struts, DOT NET etc..
☐ libraries are up-to-date
☐ system calls have their return status checked
☐ efficient memory usage
☐ no exposures to buffer overruns
☐ code, services, commands and processes are executed using minimal privileges (least privileges)
☐ code has no back doors
☐ debugging code and test harnesses have been removed

Every Checklist is Different

This checklist is extensive but not complete.

Sources:
• Modelled after: OWASP-Web-Checklist
• Secure Code Review Checklisthttps://arch.simplicable.com/arch/new/secure-code-review-
checklist)
• Internal Software Secured Checklist
• Code Review Checklist – To Perform Effective Code Reviews
• Java Code Review Checklist
• Software Integrity
• Security Audit Checklist: Code Perspective
• Stop More Bugs with out Code Review Checklist

Animesh Digitally signed by

Animesh Roy

Roy Date: 2019.06.23

22:39:56 +05'30'
Anir0y