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 logout someone from any HTTPs website:
1) Alice log 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 (this website need not exist at all as explained below) in any plain other HTTP website Alice is visiting ;
3) Alice's browser fetch 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.
Using a slightly 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 informations on the fake user account. Bob then can log on this fake account to get Alive private information:
1) Bob creates an account on https://example.com with login ;
2) Alice logs on https://example.com
3) Bob log on https://example.com using his fake account and get a session ID for this fake account ;
4) Bob MITM a 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 set a cookie using his session ID ;
7) Next request of Alice on https://example.com is infact using the fake account but she might not notice unless she checks here login ar every page ;
8) Alice submits some private data on the website (she adds a bookmark, make a search engine request, uploads some photos …) ;
9) Bob logs on the fake accuont and retrive Alice 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" (mentionned by fatfredyy).
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).