A question I often get asked about manual security code reviews (manual source code review) is how can a manual review process be clear, consistent and repeatable? I’m going to share some of the things I do to try and make sure security code reviews aren’t seen as a black box process filled with security professionals practicing some kind of ninja skills on the source code.
To help me with security code reviews I have created a checklist that started off quite small and has grown to contain around 60 different items. I know some people don’t like the checklist approach but I think it is great for providing clarity and repeatability to the security code review process. What I find interesting and at the same time disappointing is that a quick Google for security code review checklist returns very few results that are useful. The only decent checklists for security code reviews thrown up by Google are those from Microsoft which are understandably written for the .NET world.
This reminded me of my reasons for creating the principles of secure development because again there is no one making this easy to understand. The OWASP Code Review Guide is a good example of a project which aims to help people but misses out the simple things like a list of checklist items which would really help people. The guide provides some very useful information on what to look for when you are carrying out security code reviews but its 200+ pages is a daunting prospect for someone new to the application security world. The guide is just another area of application security where the KISS (Keep It Short and Simple) approach should be followed rather than a constant desire to add more.
I have seen great traction and support for the principles approach to secure web application development that we have created so I have attempted to take the same approach to security code reviews. The checklist includes some questions that relate to security items I feel should be contained in application design documents as well as things to look for in the source code. These checklist items should ideally be reviewed when the application design document is produced rather than at the end of the SDLC process (this assumes that security is integrated throughout your SDLC).
I will post the security code review checklist items for one or two secure development principles each week for the next 4 or 5 weeks with an explanation of each checklist item so that you can use them in your own review process.
You will need to choose one of three different answers for each checklist item: YES, NO or 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 week’s blog post will cover the checklist items for Input and Output Validation. The checklist items based on the content of design documents might not be applicable for every security code review.
Input and Output Validation
We have 9 checklist items for Input and Output Validation which you can see below:
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 data traverses trust boundaries. We should review these points in the source code to ensure that data validation has been implemented correctly.
This item requires the reviewer to identify how the application performs input validation. The input validation in the application should check the content as well as the minimum and maximum lengths for all data types received and processed.
An often overlooked step in application security is the canonicalization of data prior to performing input validation. This can allow encoded attack strings to bypass the input validation functions you have implemented.
Applying input validation on only the client or server side could allow vulnerabilities to occur in your application. The application should always enforce data validation on both the client and server side.
If the application receives XML requests it should validate the XML against an XML schema.
This checklist item is a reminder that any values that an external user could manipulate must be validated.
We should always be aware of where the output from our application is going to end up (i.e. in a URL) and apply the correct type of encoding. This checklist item will identify the points in the application where externally supplied input is used as output from our application and ensure that the correct encoding has been applied.
We should always be aware of where the output from our application is going to end up (i.e. in a URL) and apply the correct type of encoding. This checklist item will identify where any data is output from our application and ensure that the correct encoding has been applied.
These checklist items will allow you to carry out a security code review which checks that the input and output validation 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.