Secure Code Review

From MediaWiki.org
Jump to: navigation, search

Contents

[edit] Secure Code Review

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

[edit] Code review guidelines

  • 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

[edit] What to look for in a code review

[edit] Code must

  • 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

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

  • 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

[edit] Code should

  • 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
Personal tools
Namespaces

Variants
Actions
Navigation
Support
Download
Development
Communication
Print/export
Toolbox