Secure Code Review
From MediaWiki.org
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