Last week I posted the first part of my security code review checklist which will help you review source code for input and output validation issues. I was happy to see how many people liked the first checklist items post and I always appreciate any feedback you have!
This week I will be covering the checklist items for the Authentication and Authorisation secure development principles. The checklist items based on the content of design documents might not be applicable for every security code review.
The checklist items will have one of three different answers: YES, NO and N/A. They are worded in such a way that a NO answer is a security failure (this might be different in your own environment) and an N/A should be accompanied by a short description as to why you feel it is N/A.
This first checklist question relies on the design document including security focused data flow diagrams such as those created for use in threat models. The entry points and trust boundaries identified on these diagrams can help you pinpoint areas of risk.
The diagrams mentioned in the previous checklist item can also help with the second item on our checklist. We are looking at the data flow diagrams and identifying points where resources are accessed across trust boundaries. We should review these points in the source code to ensure that any relevant changes in authorisation are enforced.
This checklist item will review the applications design to ensure that the security of user credentials in transit has been considered. To confirm that the application has been developed in a secure manner you should review the source code to ensure that user credentials are protected in transit.
This checklist item will be looking at the error handling principle for authentication points in the application. We are specifically looking at how a failed authentication is handled and making sure that a generic error message is returned in this situation.
If the application requires access to databases the user account/s being used must be defined in the design document. The level of access must also be defined and reviewed.
This checklist item covers all of the user accounts being used by the application. We need to confirm that least privilege access has been granted to all of the accounts used by the application.
This item is similar to the user credentials item we mentioned earlier. The first item focuses on usernames and passwords whereas this item covers the secure transmission of tokens such as cookies and Session ID’s.
To prevent brute force attacks against our authentication process the application should automatically lockout accounts after a predefined number of failed logon attempts. The failed logon attempts threshold will depend on your own standards but I generally suggest that 3-5 failed logon attempts should result in an account being locked out.
The application should enforce the use of strong passwords for all user accounts. The required strength will again depend on your own standards but I like a minimum of 7 characters and 3 of 4 character types (a-z, A-Z, 0-9 and special characters) in the ASCII printable range.
These checklist items will allow you to carry out a security code review which checks that the Authentication and Authorisation secure development principles have been implemented correctly.
I would love to hear any feedback you have on these checklist items as well as any additional items you think should be in the checklist.