When sending a cookie back to the server, the browser does not send back the "secure" flag: the server cannot check whether the sent cookie really come from the "secure" origin (https://example.com). It might instead come from the corresponding non-secure origin (http://example.com). Moreover an attacker can use MITM to overwrite any cookie using the non-secure origin: this injected cookie will be sent by the browser to the secure origin as well.

So an attacker could use a MITM to log out someone from any HTTPs website:

  1. Alice logs into B's https://example.com site (the site may be a full HTTPS website without any http:// corresponding website) and get a "secure" cookie;
  2. Bob uses MITM to inject a <img src="http://example.com"> (this website need not exist at all as explained below) in any plain other HTTP website Alice is visiting;
  3. Alice's browser fetches the "image" at http://example.com/;
  4. Bob forges a response (the http://example.com website might not even exist at all) and resets the session cookie to any value;
  5. Alice is logged out example.com.

Session pinning

Using a slight variation, Bob could create a fake user account on https://example.com, log into it, get the session ID and set it using the same technique on Alice's browser. This way Alice could be fooled into submitting private information on the fake user account. Bob then can log on using this fake account to get Alice's private information:

  1. Bob creates an account on https://example.com with login;
  2. Alice logs on https://example.com
  3. Bob logs on https://example.com using his fake account and get a session ID for this fake account;
  4. Bob MITM a <img src="https://example.com"/> on any plain HTTP website Alice is visiting;
  5. Alice's browser fetches the "image" at https://example.com;
  6. Bob forges the response and sets a cookie using his session ID;
  7. Next request of Alice on https://example.com is in fact using the fake account but she might not notice unless she checks her login at every page;
  8. Alice submits some private data on the website (she adds a bookmark, makes a search engine request, uploads some photos …);
  9. Bob logs on using the fake account and retrieves Alice's private data.

Is there any reason why it doesn't work? Is there any way to avoid this? Does this attack have a name? Is there any reference or discussion available on this (OWASP, security papers ...)? Has this vulnerability been used in practice? Is there any solution/plan to work around it by adding functionality to the browsers (maybe some new cookie header for per-origin cookies)?

This is slightly discussed in RFC 6265 section 8.6 "Weak Integrity".

What I'm describing is best described by the paper "Robust Defenses for Cross-Site Request Forgery" 2 as "Cookie Overwriting" (mentioned by fatfredyy).

Possible solutions

  1. Use HSTS with includeSubDomains

    Not very well supported (older browsers). Bootstrap issue as pointed out in an answer by Hendrik Brummermann.

  2. Use SSL Session ID for session tracking instead of cookies

    The SSL session ID cannot be injected by an MITMing attacker. Are the sessions stable with this kind of setup?

  3. Use client certificate authentication for session tracking instead of cookies

    Not very user friendly (and lack of standard "logout" functionality).


Yes, this attack works in practice.

For a site owner there are basically two ways to mitigating this attack:

  • HSTS, but HSTS itself is vulnerable to an active attacker on the first request.
  • display the username / profile picture of the logged in user, but this is vulnerable to a cleverly timed attack.

In theory this attack could be prevented by a protocol change: If the browser had included the domain and http/https information in the cookie header, the server would be able to verify it.

Browsers could deleted secure cookies on any attempt of modification by a http source. Just ignoring such modifications is a bad idea because it will break logout on some pages.

  • As I don't expect my username to change without notice, I don't check it on any page (I don't check it at all). I doubt anybody does that … – ysdx Jul 19 '12 at 22:33
  • Indeed adding a modified Cookie management would prevent this vulnerability. Some kind of per origin cookie space would be a quite useful for security. – ysdx Jul 19 '12 at 22:35

I don't really understand what you are saying, but I will try to understand/explain a few things.

First of all, the secure flag in cookie means that this cookie value will only be send when site is accessed via HTTPS connection.

Secondly, cookies are domain and path based so they won't be send to another domain, or path.

The attack that you're describing is known as CSRF Login attack, largely neglected/underestimated and marked as small risk little impact attack (imho falsely). You can read more in: "Robust Defenses for Cross-Site Request Forgery"

And finally If attacker is able to mount MITM with HTTP there is very little we can do and nothing will be as secure as HTTPS. So I will agree with you, to be secure sites should be full HTTPS only or not at all. Also as an additional measure web browsers could prevent overriding a secure cookie form HTTP response.

  • Woops. Fixed the missing https. – ysdx Jul 19 '12 at 18:33
  • I think it's not really a login CSRF. The attacker does not get access to the user's account but inject his own (fake) account into the target's browser. – ysdx Jul 19 '12 at 18:49
  • And that is what Login CSRF is all about, attacker is substituting victim's authenticated session with his authenticated session, hoping that there will be some benefit from this action. – damiankolasa Jul 19 '12 at 18:55
  • Yes but it's slightly different from the more simple CSRF attack where the attacker triggers a login form on exampe.com: this attack can be avoided by validating a form hidden field against a user session cookie (as any other CSRF attack). In this case, as the attacker pushes the session ID, the application can't do much to prevent the attack: the classical CSRF protections won't work against this kind of attack. – ysdx Jul 19 '12 at 19:09
  • "to be secure sites should be full HTTPS only or not at all". Indeed but in this attack, the plain non-SSL enabled website might not even exist at all. Not having a plain HTTP website is not enough, you have to prevent the browser from trying to access the (non-existant) plain HTTP website using HSTS. – ysdx Jul 19 '12 at 19:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.