Secure Code Review

From MediaWiki.org
Jump to navigation Jump to search

Secure Code Review[edit]

Before programs are released to customers, the source code should be reviewed for security vulnerabilities and control reliability.

Code review guidelines[edit]

  • All code should be reviewed
  • Programmers should never review their own work
  • Reviewer must have security training
  • General test cases, including boundary conditions and constraints should be created to go with code to clarify testing
  • Code should have a reasonable amount of comments to ensure fast code review
  • Code reviews should produce auditable evidence that they were performed with some kind of report capturing the reviewer's name, time of review, specific pieces of code reviewed and comments

What to look for in a code review[edit]

Code must[edit]

  • Validate all user input (anything returned from a browser) for appropriateness (length, type, format, range)
  • Analyze user input for command injections before it is encoded into SQL statements

Validate all input from outside the program for:[edit]

  • Out-of-range values
  • Invalid characters
  • Missing or incomplete data
  • Exceeding upper or lower volume limits
  • Content length exceeding maximum expected
  • Enforce program logic, execution order, and integrity of security controls to detect corruption through processing errors or deliberate malicious acts
  • Use mechanisms to recover securely from unexpected failures
  • Have the ability to record all possible failure codes
  • Not have developer backdoors
  • Not have hard-coded debug commands
  • Not have hard-coded credentials
  • Not have unused calls and code that don't accomplish anything
  • Not use internally-developed cryptographic libraries
  • Not ignore or fail to use return codes

Code should[edit]

  • Use configuration information from configuration files
  • Use Hostnames not IP addresses for identifying hosts
  • Use security-related libraries whenever possible instead of re-inventing the wheel
  • Have bounds checks on function inputs
  • Encrypt the storage of sensitive strings such as password or crypto keys
  • Not generate overly informative user delivered error messages without configuration override
  • Not log sensitive data such as passwords, credit card numbers without configuration override
  • Not have hidden malicious code, sometimes indicated by embedded assembler code