My next class:

Sessions with(out) cookies

Published: 2013-07-23. Last Updated: 2013-07-23 18:31:53 UTC
by Bojan Zdrnja (Version: 1)
3 comment(s)

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

Keywords: cookies sessions ssl
3 comment(s)
My next class:

Comments

Well... my thought on the matter is: use both SSL session ID and a cookie.
Require them to both match: and if they don't, forced expiration of the session.

You could also pass a canary value on every HTTP form, and for every GET request

The idea is if you have more than one way of identifying a session, and you verify all of them before the application accepts any user input, then perhaps you hedge the risk that certain methods might be used to hijack or coopt a user's session (XSS, CSRF).
Using SSL session IDs to "back up" normal session cookies makes a lot of sense. However, I don't think it will help with CSRF. Requests generated by CSRF would just use that same SSL session.
testing email replies

Diary Archives