For part three of our Web Application Auditing series we’re going to focus on controls that should surround the session management system. Having performed evaluations of a number of web applications over the years and having worked to train developers how to create secure web applications, I can tell you that session management is one of the most poorly understood aspects (see here, here and here, for example) of web application development.
One of the reasons for this is that the various web frameworks available (ASP, Spring, Struts, Rails, PHP, etc.) go out of their way to conceal the details of how sessions are managed to allow the developer to focus on more interesting things. Unfortunately, this leads to an oversimplification of one of the key controls for the security of an application. This is further complicated by the fact that most of these frameworks have weak or even insecure session management built in.
What to check for?
Here are a few things to check for. First of all, after the authentication, where user credentials are exchanged, is completed, the session ID or session token is used to re-authenticate the user with every request. The reason for this is that web servers and the HTTP protocol is a stateless protocol. In other words, each transaction is treated as a completely discrete request with no relationship to any other requests, at least from the point of view of the server itself. Maintaining state, keeping track of who this user is and what they are doing, is all implemented at the application level, or perhaps within the API through the library of whatever framework is in use.
Since all subsequent requests are using the session ID to continue to authenticate the user it is critical that the session ID be sent over a secure channel. There are cases, of course, where this is not necessary. For instance, if you were creating a search engine and using a session ID to keep track of the user there would likely be little concern over a third party discovering the session ID and potentially impersonating someone. On the other hand, if you’re talking about a bank application, clearly the session ID is just as sensitive as the username and password since it becomes a short term secret used for authentication and, effectively, authorization.
In addition to making sure that the session ID is sent over a secure channel, it is at least equally important to verify that the session management library generates secure session IDs. This means that the session IDs are significant in length (we usually recommend at least 64 bytes), random and are not derived from the user information in any way. How can we test this? There are some very handy tools available for just this purpose.
The first that we’d recommend you look at is WebScarab available for free from OWASP. Amongst many other excellent features, WebScarab has a session ID analysis section that will produce a nice graphical representation of a series of session IDs. (For a 20 minute video demonstrating some of the features of WebScarab, including the session ID analysis portion, please see here!) The second tool that we’d recommend is Burp Suite. Burp is an outstanding tool for analysis of web applications and performs a very thorough series of statistical analyses of session IDs automatically, providing a level of assurance beyond, “They look good.”
So, in short, here are the items that must be tested for session management:
- Are session IDs sent over a secure channel?
- Are the session IDs sufficiently random?
- Are the session IDs related in any way or generated from user provided information?
- Are there any protections to detect tampering with session IDs?
- Will the session IDs expire after a certain period of time even if the user does not use a “Log Off” procedure?