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.
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.