Cenzic 232 Patent
Paid Advertising
web application security lab

MITM, SSL and Session Fixation

23 posts left…

It’s been known for a long time that HTTP can set cookies that can be read in HTTPS space because cookies don’t follow the same origin policy in the way that JavaScript does. More importantly, HTTP cookies can overwrite HTTPS cookies, even if the cookies are marked as secure. I started thinking of a form of session fixation during our research that uses this to the attacker’s advantage. Let’s assume the attacker wants to get access to a user’s account that’s over SSL/TLS. Now let’s assume the website sets a session cookie prior to authentication and after authentication the site marks the cookie as valid for whatever username/password combo it receives.

First, the attacker goes to the website before the victim gets there so he can get a session cookie. Then, if the victim is still in HTTP for the same domain the attacker can set a cookie that will replay to the HTTPS website. So the attacker sets the same cookie that he just received into the victim’s browser. Once the victim authenticates, the cookie that the attacker gave the victim (and knows) is now valid for the victim’s account. Now if the victim was already authenticated or had already gotten a session token, no big deal. The attacker overwrites the cookie, which at worst logs the user out. Once the victim re-authenticates, voila - session fixation. Now all the attacker has to do is replay the same cookie in his own browser and he’s in the user’s account.

2 Responses to “MITM, SSL and Session Fixation”

  1. Eric Duprey Says:

    Hmmmm.. I kind of figured this was an obvious way to exploit a session fixation vulnerability against an SSL/TLS target. I use it as an example when describing session fixation attacks (obviously the target site would have to be vulnerable and you’d have to be MITM).

    From the non-MITM angle, what about setting a wildcard / subdomain cookie via XSS on another compromised host on the same domain?

    E

  2. Steven Says:

    session_regenerate_id();