50 Point Checklist for Secure Code Review
Secure Code Review identifies possible security vulnerabilities related to features and design in the application. This process may be initiated at the beginning of the software development life cycle and be continue even when the software will be in use in production. It is the most effective technique to eliminate security issues effectively if performs correctly. In this article, code reviewers maybe use a 50 point checklist for auditing software applications for secure code review. In this article, I have compiled a Checklist for Secure Code Review that may be followed while performing code review.
How to perform Secure Code Review?
Effective source code review can't be done merely using tools or by human effort. This activity is a combination of both. For example, security code review tools may help identify some issues related to identifying vulnerable functions. Simultaneously, human effort is needed to identify flaws relating to business flaws and logical issues. The two-step approach may be employed for effective secure code review:
- SAST or Static Application Security Testing tools must scan the source code repository to identify vulnerabilities related to vulnerable functions or string patterns. DAST or Dynamic Application Security Testing must be used to identifying run-time vulnerabilities such as cross-site scripting. This step helps in the coverage of application that is difficult to achieve by using only human effort.
- Code auditor maybe sits with the developer to understand the functionalities of the application and different directories in a source code repository. Further, SAST and DAST tool reports analyze by code auditor and identify real vulnerabilities. Also, step 2 identifies logical and design flaws that may not be visible in step 1.
50 Point Checklist for Secure Code Review
|1. Any extraneous functionality implemented in the application.|
|2. Any sensitive information used by the application.|
|3. Secrets must be accessible on proper authentication.|
|4. Untrusted input is not acceptable by the application. Validate user input by testing length, range, type, etc.|
|5. Business logic implemented in the application needs to be validated.|
|6. Are there any backdoor for authentication for admin users.|
|7. Check for default configuration like Access- ALL.|
|8. Data validation must be done on the server-side.|
|9. Check the login page available only on the secure channel (over TLS).|
|10. Ensure error messages do not leak any information.|
|11. Ensure username and password not available in logs.|
|12. Check password complexity is sufficient enough.|
|13. Check for password expiration mechanism.|
|14. For critical applications, ensure multi-factor authentication enforce and strictly enabled.|
|15. Bruteforce preventable mechanisms (e.g., Captcha) must be employed.|
|16. Not allow the user to enter multiple guesses in Captcha after an incorrect attempt.|
|17. Ensure security checks implemented before processing inputs.|
|18. Ensure PINs use as two-factor authentication have a short life-span and are random.|
|19. Ensure session ID length must be at least 128 bits.|
|20. Ensure session cookies must be encrypted.|
|21. Ensure session time out inactivity is enforced.|
|22. Ensure implementation of session timeout mechanism.|
|23. Ensure active sessions must be warned if accessed from a different location.|
|24. Ensure session elevation mechanism correctly implemented.|
|25. Ensure keys or secrets not be hardcoded in source code.|
|26. Ensure the application uses a certified implementation of cryptographic algorithms.|
|27. Ensure protection at rest mechanisms is implemented.|
|28. Implementation of HTTP Strict Transport Security (HSTS) for critical interfaces.|
|29. Ensure no proprietary algorithms used without proper validation.|
|30. Source code must be properly commented on to increase readability.|
|31. Ensure logging mechanism implemented for critical functionality.|
|32. User and Role-based privileges must be verified thoroughly.|
|33. Ensure X-Frame-Options: deny implemented correctly.|
|34. Ensure X-XSS-Protection: 1; mode=block to mitigate XSS attack.|
|35. Ensure the application store password by using the right cryptographic mechanism.|
|36. Ensure notification must be triggered on the registration confirmation or forgot password functionality usage.|
|37. Ensure sensitive information transmitted in encrypted form.|
|38. Ensure database credentials stored in an encrypted format.|
|39. Ensure no components such as libraries, frameworks, etc. are updated to the latest version.|
|40. Ensure all redirects/forwards are based on a whitelist instead of the blacklist.|
|41. Ensure the same-origin policy is correctly implemented.|
|42. Ensure payment-related information such as credit card numbers etc. must not be logged.|
|43. Ensure generic error page is implemented on application failure.|
|44. Ensure application changes logging level if detects any attack.|
|45. Check how the administrator knows that the application is under attack.|
|46. Check for a race condition.|
|47. Check for a buffer overflow vulnerability.|
|48. Check application enforce users to change the default password on the first login.|
|49. Check application use any elevated OS/system privileges for external connections/commands.|
|50. Check for authorization-related issues.|
Code review is a skill that requires a lot of hard work. The more you involve in the code review activity, the more you know the techniques involved in this activity. But if you have one checklist that helps you identify all points, it definitely helps you do an effective code review.
Subscribe us to receive more such articles updates in your email.
If you have any questions, feel free to ask in the comments section below. Nothing gives me greater joy than helping my readers!
Disclaimer: This tutorial is for educational purpose only. Individual is solely responsible for any illegal act.