Talk:Testing for Session Management

Weak Session Tokens

Manual

The session token can either be generated by the web application, or created using the underlying framework. There are several popular framework products, here are the identifications of each:

• ASP Session ID, part of the ASP Session object. Identified by the format "ASPSessionID=<value>, or ASPSessionID<value1>=<value2>
• ASP.NET – Session IDs in ASP.NET are either passed in a cookie, or are displayed in a mangled form in the url. ASP.NET Session IDs in cookies will be identified by "ASP.NET_SessionID=<value> in the cookie. ASP.NET cookie-less session ID - If the framework is ASP.NET and the URL is in the following form: http://www.MySite.com/<value>/<requested_page>, the application is most likely using ASP.NET cookie-less session ID management.
• Java – Java session tokens are usually in the format of "jsessionid=<value>". Products that implement this mechanism are IBM WebSphere, BEA WebLogic, and many others.
• Coldfusion – The distinguishing mark of CF are the CFID and CFTOKEN variables in the cookie. These two values combine the session value. ColdFusion based applications often use the J2EE jsessionid name for their session token.
• PHP – the session token variable in PHP is called "PHPSESSID". It is very often passed in the URL instead of the cookie, which is insecure and should be watched for.

The above list is far from being complete. Additionally, there is always the possibility the default session parameter in the cookie has been changed. But most cookie IDs encountered during security testing are in one of the above forms.

If the mechanism is homegrown, issue multiple requests to obtain a large number of session tokens (writing a script that will get hundreds of tokens should be considered as an option). Examine the tokens, checking for similarities, patterns, incrementing, or otherwise identifiable weaknesses.

Suggested Tools

OWASP's WebScarab features a session token analysis mechanism. You can read How to test session identifier strength with WebScarab.

Whitebox Testing

In a white box test the options depend on the actual level of the whitebox-blackbox balance. If the application source code is available – examine the session mechanism (ask shay). Otherwise, talk to the r&d personnel responsible for the application, and check whether they are using a commercial or homegrown session mechanism. In case they are using a homegrown mechanism ask to see the structure of this mechanism, the actual code responsible for generation of the session token. Check whether it is sufficiently random, check for the length of the token. Especially sensitive applications could require stronger session tokens than others. Additionally, try to talk to the team or person responsible for this mechanism, understand why there was a need for a homegrown mechanism – and check for underlying security problems and misconceptions.