As long as an attacker can remotely force the victim to use a known session cookie that becomes authenticated, you’ve found session fixation, but it’s one of those flaws that can be achieved in multiple ways that are subtly different from one another. In this particular instance the session fixation attack ran like this:

1. The attacker makes up a session cookie

Yes, the application accepted client-generated cookies.

2. The attacker makes a specific request using the fabricated cookie

This was a bit odd but if the session cookie from a request was not recognised by the application (whether it was made up or, more usually, it had just been set by the previous response page) then a background XHR request was made that effectively “authorised” the cookie. Okay, whatever, so the attacker does this.

3. The login page suffered from XSS so the attacker crafts a malicious link to set the known cookie on the victim.

The malicious link was something like this (I’ve removed the URL-encoding to make it easier to read):

https://www.example.com/login?param="><script>document.cookie="PHPSESSID=attackerCookie; path=/login; expires=Tue, 06-Aug-2024 00:00:01 GMT"</script>

In more “traditional” session fixation the attacker’s cookie is a parameter in the request that the attacker tricks the victim into making, so using XSS seems a bit like cheating. Unfortunately (for me) the application didn’t accept a session cookie in the “traditional” way and XSS was my only option. OWASP does credit XSS in its description of session fixation but, that aside, not only did XSS help the session fixation attack but the session fixation flaw helped the XSS attack…One reason for this was that a simple document.cookie session hijack through XSS was restricted by the response to the above request:

Set-Cookie: PHPSESSID=serverCookie; path=/; secure; HttpOnly

Because of the httponly flag, the XSS payload could not pull out the session cookie and send it to the attacker. Of course, many other interesting XSS options are still possible, such as rewriting the form’s action attribute so that the login credentials would be sent to the attacker. However, one advantage of the session fixation approach (apart from the interest of seeing it working) is that nothing is sent to the attacker. Furthermore, as I’ll explain later (and you may have already spotted from the XSS payload) this attack has the potential to be more long-term than knowing the username and password.

The httponly flag has another effect: the XSS payload can neither read it nor overwrite it. This behaviour isn’t standardised, it’s one of those grey areas that Michal Zalewski covers so well but in this case it’s not so grey. IE 10, Chrome 37 and Firefox 30 all behaved in the same way. But you might have noticed that the XSS payload included a path of /login when it set the session cookie. This is where the attacker wins as now the browser doesn’t see this as an overwrite but as a different cookie altogether…

4. The victim logs in and the session cookie becomes authenticated

The server-generated session cookie included a path=/ directive so when the victim logs in to /login the attacker’s cookie has precedence (in that it’s listed first) because the path is a more specific match to the target page:

Cookie: PHPSESSID=attackerCookie; PHPSESSID=serverCookie

The application processed the first cookie with the login, thus the attacker’s fabricated cookie became authenticated and was associated with the victim’s account. Of course if the session cookie had been changed after authentication, which is best practice, the attack would have failed. Note that the attacker can also set the domain attribute of the cookie to .example.com to try to widen the impact of the attack.

5. The attacker uses the known session cookie to masquerade as the victim

The last thing to mention is the long-term nature of this attack. Although logging off did detach the session cookie from the victim’s account, leaving it unauthenticated, the application did not clear it (again, best practice). So the next time the website is visited, the attacker’s session cookie will again be offered, accepted and authenticated. Because the XSS payload effectively makes the cookie permanent by setting a long expiry date, the attacker has access to the account of anyone that logs in using the compromised browser in the future. Of course, the persistence of the attack dies as soon as the browser’s cookie cache is cleared – but how often does that happen? For what is, after all, a reflected XSS attack, you’d be certain to get a good return. Indeed, if the browser is shared among users (e.g. at home or at internet kiosks), a single XSS attack can exploit multiple users of the website, making it a one-to-many attack, which you don’t tend to associate with reflective XSS.

I’m not claiming any of this is particularly novel, by the way. I just enjoyed finding the XSS path trick for myself and using it with session fixation to poke fun at httponly and to create a more persistent version of a reflective XSS attack. It also demonstrated that best practice points, although seemingly trivial when taken alone, can help to stop or mitigate more complex attacks.

No secure flag

But in this case it didn’t seem to matter so much. Why? Because port 80 was shut: the whole application was served over HTTPS so the cookie would never have the chance to escape over HTTP, even if an attacker could engineer such a scenario – for example, by enticing the victim to click on a HTTP link (although more on this shortly). This is because the TCP connection must be set up with the 3-way handshake before any application data is sent over it – and since the port was closed, the connection falls at the first hurdle ^[1].

Nevertheless I still reported the missing secure flag because the application was in a test environment and what if port 80 was open on the live server? Now the cookie is more vulnerable. And there’s another consideration. While port 80 on the host under scrutiny (e.g. secure.example.com) was filtered, port 80 may have been open on another related host (e.g. test.secure.example.com or www.example.com). If the attacker used a HTTP link to another such host instead, then when the link was clicked, the cookie could be transmitted. You’ll notice a “could” there – it depends on any accompanying domain and path restrictions on the cookie when it was set (and possibly how the browser interprets them).

foo.example.com sets a cookie over HTTPS with domain=.example.com

A request to bar.example.com over HTTP includes the cookie

The classic protocol-host-port tuple of the Same Origin Policy (SOP) doesn’t apply to the scoping of cookies. If it was, we wouldn’t need the secure flag because, assuming the cookie was set as secure over HTTPS, the request over HTTP would be a change of protocol and port, so it wouldn’t be transmitted. Cookie security pre-dates SOP as we know it (or sort of know it!) and its definition of “same origin” is different. I recommend Michal Zalewski’s Browser Security Handbook or his book The Tangled Web for more details, then fire up your web proxy and experiment!  And it was while doing just this that I discovered another side to the secure cookie.

I was testing the rules applied to JavaScript’s access to cookies (as opposed to the rules applied to transmission). I normally think of httponly as the principal attribute governing access to cookies by JavaScript but that’s not so. The domain and path attributes also play a part so that the browser’s policy for cookie access by JavaScript mirrors the transmission policy, which makes sense when you think about it. For example, if a cookie was set with the domain restricted to foo.example.com, it wouldn’t be transmitted with a request to bar.example.com so why should JavaScript from bar.example.com be able to access that cookie?

For the same reason, the secure flag also has a role in determining JavaScript’s access to cookies. I found that a cookie set as secure but not httponly was inaccessible to JavaScript delivered over HTTP from the same domain and path. This was independent of whether the cookie was set over HTTP or HTTPS. Again, the reason is because the cookie would not be transmitted under those conditions.

This all makes complete sense, it’s just that I’ve not seen any reference to this behaviour in the likes of the Web Application Hacker’s Handbook, The Tangled Web or the cookie RFC 6265. I guess it’s just implicit from the specification but sometimes it’s not until you think things through that the implicit becomes obvious! One thing to note, though, is that although the HTTP-delivered JavaScript could not access the secure cookie, it could overwrite the cookie – what’s known as “clobbering”.)

Incidentally, Internet Explorer 10 seems to have corrected the bug noted in the Browser Security Handbook:

There is no way to limit cookies to a single DNS name only, other than by not specifying domain= value at all – and even this does not work in Microsoft Internet Explorer…

It appears this statement covered IE versions 6, 7 and 8. Well, I can’t speak for 9 but with IE10 I noticed that a cookie from foo.example.com with no domain attribute wasn’t later sent to example.com.

To finish off, remember that you can only set the secure flag if the application is designed with this in mind since any HTTP request will be missing cookies that have been set as secure. An obvious side effect of this, for example, could be that the newly authenticated session management cookie set over HTTPS is withheld over HTTP, effectively logging off the user. Of course, whether or not the application should revert to HTTP following secure authentication is another matter!

===== UPDATE =====

^[1]   Dafydd Stuttard, aka PortSwigger, pointed out a neat bypass using the link http://www.example.com:443. Now the TCP connection succeeds and the browser sends the HTTP request. The SSL connection will of course fail but it’s too late, the session management cookie has gone up in the plain text request. (This is why he wrote the Web Application Hacker’s Handbook and I didn’t.) He also noted that since the attacker is in a position to sniff, having seen the SYN to port 80, the SYN/ACK could be spoofed in order to trick the browser into thinking the port is open. Thinking about this further, in an open Wi-Fi network the attacker could do this without even being an active man-in-the-middle using the Airpwn principle.