Eliminating session hijacking... forever

Jim Manico, over at Manicode, is doing an interesting thing: he is trying to convince the maintainers of every web application stack component everywhere (e.g. browsers, web servers, libraries) to implement the HttpOnly mechanism  (read more on HttpOnly in Mitigating Cross-site Scripting With HTTP-only Cookies). Actually, he is doing more than that—in many cases he is fixing things himself and submitting the patches. It's his HttpOnly Crusade.

The general idea behind HttpOnly is to prevent the disclosure of session tokens to JavaScript, which would, in turn, reduce the likelihood of session hijacking attacks. It's a noble idea, but one which is very difficult to succeed. The problem is that we are dealing with a leaky bucket. HttpOnly deals with one of the leaks, but it doesn't do anything about the others. And there are many leaks to take care of. If you go through Jim's blog posts, you will find that AJAX requests will also need tweaking (to hide the cookies marked with HttpOnly), and there is not even mention of session tokens embedded in request URIs, or embedded in request parameters. There is no doubt that an implementation of HttpOnly in all software components would raise the bar and make us more secure, but it won't solve the problem. In this particular case I would prefer to replace the entire bucket.

Our real problem is that session management is not standardised, forcing every application platform (and many applications) to provide its own implementation. Why is this bad?

1. Implementing session management correctly is not trivial. First versions of many implementations have been found to be incorrect and, thus, insecure.
2. It's a waste of time. Session management is best abstracted and handled by the underlying platform or library.
3. Application-level implementations of session management (all implementations today) are inherently vulnerable to session hijacking. We must move session management to a different layer in order to be able to implement it securely (see below).

Why is session hijacking possible in the first place? The HTTP authentication model, as originally envisioned, is not vulnerable to session hijacking because it requires authentication on every request. Session tokens are still needed to identify which requests are part of a session, but since authentication always take place there can be no hijacking. The HTTP authentication model was lacking in many other respects (e.g. there were no provisions to log people out, expire sessions, and so on), so most people simply decided not to use it. In the currently dominant session management model authentication is done only once per session, which turns session tokens into time-limited password surrogates, and thus valuable. Anyone who knows a session token can resume the session it refers to.

There are two ways to solve the session hijacking problem cleanly:

1. Perform authentication on every request, thus making session tokens worthless (as far as hijacking is concerned). You can do this today in certain circumstances, for example if you are willing to use any of the HTTP authentication methods (Basic or Digest), or if your application uses client SSL certificates (in this case all you need to do is to attach the client's SSL certificate to the session, and check that it is the same on every subsequent request).
2. Start a new RFC effort to define session management, and then implement it in a layer other than HTTP. We already have the ideal candidate for this function—SSL. SSL actually already understands sessions (they were added to version 3 to increase performance) so only a few tweaks would be needed to make the mechanism suitable for web applications.

Comments

[Ronald van den Heetkamp]

Well, HTTP authentication is still vulnerable to CSRF or -session riding- and therefore still vulnerable to temporary session hijacking depending on flaws in the application which can result in permanent session hijacking -again depending on application flaws- Assigning certificates doesn't solve it either, that only raises annoyances to end-users and it still remains vulnerable to CSRF in my opinion, just like unique IP assignment. That is, unless I'm missing something?

[Ivan Ristic]

No, you are not missing anything. CSRF would remain a problem. It's a different attack vector where, rather than hijacking the session, the attacker sort-of hijacks the browser. CSRF too can be eliminated by a proper use of sandboxes. (I wrote about this a long time ago, see http://blog.modsecurity.org/2005/07/web-security-im.html and http://blog.modsecurity.org/2006/06/secure-browsing.html) By placing each site/application into a completely separate security zone, isolated from other sites, you prevent CSRF. But neither approach deals with XSS, which can be prevented only by writing the applications properly (i.e. encoding all output as needed).

[Jim Manico]

Ivan,

Interesting post. The goal of my crusade is only to plug up one leak in the "leaky bucket" of Web Application Security. HttpOnly will help lock down today's applications. JavaScript should never need to read a cookie-based session id, ever. HttpOnly is an excellent defense-in-depth mechanism to stop this vector of attack (JavaScript XSS session hijacking attacks). That is why it's been supported by IE6/7, FireFox2 and Opera 9.5 with Safari soon to follow. It is by no means a silver bullet (there is no such thing) it's only one mechanism - one layer - to help stop session hijacking attacks. My blog does not address the security anti-patterns of "session tokens embedded in request URIs" (session rewriting), or embedding session id in request parameters (poor quality programming). HTTP Basic and Digest seem like poor ways to handle authentication - HTTP Basic, for example, stores the username and password as base 64 encoded data! And neither mechanism provide for logout capacity.

I agree with you, the best way to handle state is by using client SSL certificates. But the overhead of PKI is a cost burden for internet facing applications with large numbers of users.

So that leads us to storing session information in secure/httpOnly cookies. Sure, we need something better in the future. The HTTP protocol is weak when it comes to state. But for today, storing session id's in cookies is best practice second to the expensive overhead of client-side SSL certificates.

The (admittedly difficult) HttpOnly crusade continues.

[Ronald van den Heetkamp]

So, HttpOnly doesn't solve anything.

Because it will substitute session hijacking for session riding. Session hijacking is as dangerous as session riding, and like I said you can obtain a permanent session hijacking through session riding, but at a minimum you trick a victim into riding on his session, and you will be able to perform many things you would if you hijacked it.

So in both cases it still boils down into securing webapplications, and not on schemes like HttpOnly. Why the SSL,PKI,EV buzzwords? because in the case of session riding (CSRF) it doesn't matter what you use or have.

[JohnT]

I'm not quite sure if I'm missing anything but XSS Tunnel, BeeF, XSS Shell and any custom XSS payload can bypass all of these restrictions. Same goes for "future SSL session control" thingy.

[Ivan Ristic]

Jim, keep up the good work! I'd like to see a foolproof session management standard, but, realistically, I don't think that's likely. Small incremental changes have historically been the only way to improve things in the complex organic world of web applications.

[Ivan Ristic]

Ronald, JohnT, eliminating session hijacking is about making it possible for those who understand security to write secure web applications. XSS is a reasonably well understood problem today, and one that can be avoided with proper coding. Session hijacking cannot be prevented, no matter what you do in code (unless you deploy with private SSL certificates, but that's not realistic in the slightest).

[JohnT]

I see your point, and you are right about coming up with a better solution for session management generally. It's not about fixing current apps because if you code it well, use SSL etc. session hijacking won't happen anyway but as an elegant and generic solution what you're saying make a lot of sense.

Even though we should keep in mind that even such a solution is not a silver bullet for session hijacking, XSS, CSRF and similar issues will still be threat but at least we might get rid of bad session management issues and terrible custom session management practices.

[Andrew Ellis]

Even with the HTTPOnly add-on it is still possible to gain the cookie information by method of XST (Cross Server Tracing.) This uses AJAX (as mentioned in the article) to actually request the page and view the response. The response headers contain the cookie data and the SessionID can again be accessed. This requires a much more vulnerable site, since the attacker needs to be able to make an AJAX request, but it is still doable. The article touched upon the dangers of AJAX, I just wanted to re-iterate this type of attack.

[Jim Manico]

@Andrew - We are trying to talk to the w3c so that future specifications prevent JavaScript from reading HttpOnly cookies out of the XMLHTTPRequest object. And you are right, if a site is vulnerable to Cross Site Tracing - it's game over.

@Ronald/@JohnT - HttpOnly doesn't "solve" anything, indeed. But it does provide one small defense-in-depth measure of protection to the web application world. These incremental steps are necessary.

[Ronald van den Heetkamp]

@Jim Manico

Why do I see SSL or those other buzzwords like EV everytime? do you know that in scripting land, SSL doesn't matter? Take a look at PayPal who uses EV and still was tricked in into XSS despite the EV? If a website has holes those certifications doesn't mean anything. it only gives people a false sense of security, and that is the last thing we should do.

Also, did you know that userland trojans can detect SSL requests being made, and switch back to regular HTTP authentication? Since the many sites allow the switch from https to http, just like GMail does. This way the line becomes sniffable again.

@JohnT

I rather educate programmers/scripters on the subject instead of putting bandages around every sore, for me this is ancient thinking. The firewall and AV syndroms: Hey let's lock 65535 ports, and allow port 80 only. Well, we saw what happened, hackers made the switch to web applications that run in userland and streams trojans through your firewall.

So restrictions isn't going to solve the problems we face, EV, SSL, virtualization doesn't solve it, sandboxing doesn't solve it, using Linux or OSX doesn't solve it. We have to educate programmers instead in my opinion to make a real change.

[Jim Manico]

@Heetkamp I was talking about client side SSL certificates as an alternative to custom authentication that necessitates session id's being stored in cookies. EV SSL Cert's are stronger server-sider certs.

Also, if an XSS vulnerability was uncovered for a website, yet the application used HttpOnly session cookies (and future browsers lock down reading of HttpOnly cookies from XML like the FireFox https://bugzilla.mozilla.org/show_bug.cgi?id=380418 bug) then the session id would not be able to be hijacked via JavaScript code.

Of course, if SSL was not used, the traffic would be sniffed. But if the session cookie was set with a secure flag, it would never be transmitted other than via SSL, regardless of a trojan forcing the request back to HTTP.

My crusade is regarding HttpOnly cookie flags for session cookies - it's not a cure all, but it will *help* secure todays web applications.

[Ivan Ristic]

@Ronald, SSL and EV certificates are part of the same web application mess, but they don't have anything to do with XSS. They were designed to deal with other problems: SSL to prevent traffic sniffing, and EV certificates to allow people to have a better idea whom they're talking to.

In response to you comment about trojans switching to plain-text communication to avoid SSL communication: I would argue that a fact that a site allows non-SSL access is a vulnerability of its own. I have proposed making SSL mandatory for all sites that pretend to be secure in my Secure Browsing Mode whitepaper.