Last Updated: 2013-07-23 18:31:53 UTC
by Bojan Zdrnja (Version: 1)
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.
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.