Security research, news and guidance

A checklist approach to security code reviews, part 2

December 18, 2009  |  Written by Security Ninja  |   Application Security   |   8 Comments

Hi everyone,

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.

Check1

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.

Check2

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.

Check3

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.

Check4

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.

Check5

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.

Check6

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.

Check7

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.

Check8

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.

Check9

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.

SN

This entry was posted on December 18, 2009 at 11:23 am and is filed under Application Security . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

8 comments   >

  1. Pingback: uberVU - social comments

  2. michal wiczynski says:

    great! really usefull !

  3. Bert проститутки says:

    I’ll take some of your suggestions and try to apply them.

  4. Nilesh says:

    Hi,
    Do we have to refer to the desing document before soing source code review? your view please….

    Thanks,
    Nilesh

  5. Jeff Williams says:

    A few really important topics that you left out of the authentication discussion: session creation, session invalidation, forgot password, remember password, authentication cookies, hashing, backend authentication, key storage, user object design.

    But more importantly, you completely skipped authorization (aka access control). This is probably the most difficult and most important part of any code review. Certainly you need to verify URL access control, function access control, data layer access control, and direct object references.

    Please check the OWASP ASVS for a start on what’s important to verify.

  6. Security Ninja says:

    Hi Jeff,

    Again thanks for your input on this, my idea behind publishing the checklist in its current format was to firstly give people a starting point but to also receive feedback from others in the industry. The main version of the checklist covers a lot of the issues you mentioned but the relevant checklist items refer to propriety code and systems of my employer and need to be re-written to make them generic in nature before I can publish them.

    I’m happy to receive feedback such as yours so I can create a more complete checklist (along with re-writing the checklist items mentioned above) and publish it for anyone to use. I can already see things from the ASVS that I want to turn into checklist questions to add to the final version of the code review checklist.

    I recently exchanged a few messages with Dinis on Twitter and I think some of the work I’m doing with the checklist (as well as a few other things) can be used with OWASP projects but I’m not sure which ones specifically, again input is appreciated here.

    SN

  7. betfair winning says:

    There’s a wealth of information here. Thanks! I’ll be back for more.

  8. Pingback: Week 51 in Review | Infosec Events

Leave a comment

VIDEOS & SLIDESHARES

Look at our latest security Videos & SlideShares

EVENTS & SEMINARS

Upcoming Security Events & Seminars

PODCASTS & DOWNLOADS

Check out our Podcasts & White Papers