Recently in a penetration test engagement I tested a WebSphere application. The setup was more or less standard, but the interesting thing happened when I went to analyze how the application handles sessions.

Virtually 99% of all web applications today use cookies in order to store session information. However, the application I tested set a very weird cookie with the following content:

SSLJSESSION=0000SESSIONMANAGEMENTAFFINI:-1

Clearly that cannot be used for session handling, however no other cookies were set by the application, yet sessions were handled correctly. After a bit of browsing through WebSphere’s documentation, I found out that WebSphere (actually IBM HTTP Server as well as SUN One Web Server) support a feature called SSL ID Session Tracking. Basically, what this does is bind web application sessions to SSL sessions. This further does not require the web application to do almost any session handling since the server performs this on behalf of the application.

However, in this simplicity lurk several potential problems:

• Since the web application’s sessions are tied to SSL channel session, any user that can somehow access the same SSL session is automatically authenticated by the target web application. While this scenario is not all that likely, it is still possible through, for example, an incorrectly configured proxy that somehow reuses opened SSL sessions – opening Burp proxy and letting it listen on the network interface in such a setup is a really bad idea.
• The web application (as it should always anyways) has to properly handle logout activities and invalidate the SSL session – since there are no cookies it must prevent the web browser from reusing the same SSL session.

On the other hand, there are several really nice features here – probably the most important being that an attacker cannot abuse vulnerabilities such as Cross Site Scripting to steal session information. Of course, XSS can still be used to perform other attacks through the vulnerable application, but session information cannot be stolen any more.

SSL ID Session Tracking is, however, deprecated in WebSphere 7.0 so it is pretty rare today. This means that the applications must use cookies to handle session information, or transfer them as parameters in requests but this is not recommended since such information is visible in logs. In essence this leaves us with cookies which are probably here to stay so it does not hurt to remind your developers to use HttpOnly and Secure parameters; it is trivial to set them and, while they are not a silver bullet, these settings can make exploitation of some vulnerabilities much more difficult.

--
Bojan
@bojanz
INFIGO IS