Is it possible to capture the cookies used by HTTPS site when cookies don't have secure flag set.
Suppose the site is https://www.example.com.
http://www.example.com does not show up, also http://www.example.com:443 does not.
Still can there be any way?
Yes.
HTTPS prevents MITM attacks. Consider:
1) you visit https://secure.example.com/ which drops a cookie on your browser
2) you then visit http://www.google.com/ however a MITM inserts
<div style='visibility:hidden'>
<iframe src='http://secure.example.com/'></iframe>
<div>
3) MITM sniffs your cookie from the request on the iframe
Or even if you (deliberately) navigate from https://secure.example.com/ to http://secure.example.com/ then the attacker doesn't even have to inject any HTML to sniff the cookie.
And then there's also the possibility of session fixation - where even if the cookie dropped by https://secure.example.com/ has the secure flag set, that's no use if it sends back a session id it received in a non-secure cookie (again set via MITM).
http://secure.example.com/ (at least enough to capture the cookie), even if the genuine server has nothing listening on port 80.
– Bruno
Jan 10 '12 at 19:47
https:, http:).
– curiousguy
Jun 28 '12 at 13:25
Agree with @symcbean, in addition here is an interesting session fixation technique:
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.
