MITM session injection/invalidation

Question

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).

Answer 1

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.

Answer 2

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.