Auditing Web Applications: Part 2

This is the second in our five part series covering how to use the Web Application Security Checklist posted earlier in our free checklists section.


There are many applications where authentication simply doesn’t make a lot of sense.  For instance, a search engine.  However, any time there’s a need to limit access or to provide an audit trail of who did what, authentication becomes a critical process.  Authentication is the process involved in proving that you are who you claim to be.

When testing the security of a web application, or verifying that it complies with the security standards required in an organization or by a standard, we need to check a few things.  The first is that we need to make sure that the authentication meets the objective for which it is being specified as a control.  In other words, if authentication is required to protect sensitive data we need to first ensure that no sensitive data is accessible before the authentication process completes.

Once we know that authentication is occurring early enough in the data transaction, our next questions need to identify how the authentication is happening.  When it comes to web applications, we can say with some confidence that Basic Authentication is almost always the wrong choice.  The long explanation of why this is is meaty enough for a blog posting all its own so we’ll say for now that it tends to use a long term secret as a short term secret and this is a bad thing.  We actually spend a great deal of time digging into this issue (ie, authentication types) in our web application auditing class.  If Basic Authentication is used it’s an absolute must to ensure that SSL is being used to encrypt not just the actual initial authentication but every subsequent transaction with the web application because of the nature of how Basic Authentication functions.

If anything other than Basic Authentication is in use then we need to turn our attention to the Session ID and Session Token (the method used to transfer the Session ID; e.g., URL rewriting or hidden form fields).  Generally speaking, there are a few basic things you must check for:

  • The Session IDs are sufficiently random (Check out Burp Intruder for a fantastic testing suite for this problem!)
  • If a Session ID was selected prior to authentication it should be discarded and a new one generated when the session is established.  This tends to protect against a Session Fixation attack.
  • Prior to performing the actual authentication the application forces interaction to a secure channel such as SSL.  In fact, non-SSL transactions should likely be refused completely after establishing the session to prevent hijacking attacks against the application.
  • The auditor should manipulate the session tracking mechanism to ensure that it is not possible to re-use or clone a session by using the session token from another system.

The last big tip for you, especially if you’re new to auditing web applications, is that after you verify that your application is fairly secure, try disabling features in your web browser to see if there are other mechanisms in place for handling sessions.  Here’s a common example:  The application uses cookies to handle the session token.  You test the application thoroughly, verifying that the session IDs are very random and that they are well protected, perhaps even with tamper-proofing or at least tamper-detection in the application.  Fantastic.  Now that you know the cookie based session management is secure disable cookies on your browser and try to use the application again.  If it still works then there’s an alternative mechanism in place for tracking sessions.  That means it’s time to start this section of the checklist all over again for the alternative method!

This is just one of the many topics discussed and taught hands on in David Hoelzer’s class, “Advanced System & Network Auditing”, available through The SANS Institute. David is a Senior Fellow with The SANS Institute and the principal examiner for Enclave Forensics. You can find a variety of topics on his blog.


2 Responses to Auditing Web Applications: Part 2

  1. […] Auditing Web Applications: Part 2 « Audit Advice & Checklists […]

  2. bknows says:

    Keep it coming. Waiting for #3! thanks.

%d bloggers like this: