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?

  • if the server on same domain(considering the cookies are set to /) is listening on a port without https, then yes if the user sends a request to the application on this port cookie will travel with the request in clear text. Commented Jan 10, 2012 at 9:33
  • @SachinKumar : Thats where the problem lies ..i dont know which other port is open. Commented Jan 10, 2012 at 9:59
  • NMAP :) look for ports with HTTP ... Commented Jan 10, 2012 at 10:19
  • nmap only says 443 Commented Jan 10, 2012 at 10:23
  • If there is no http server then you only have https - so then the plan as described by @Sachin will obviously not work.
    – Rory Alsop
    Commented Jan 10, 2012 at 12:07

2 Answers 2



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>

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

  • QQ : Consider a scenario where user is using a proxy. Would this scenario work if there is nothing listening on 80 or http any other port on the server? would the cookies travel with CONNECT method request? Commented Jan 10, 2012 at 14:08
  • symcbean : In this example secure.example.com doesnt work, the port 80 is closed. Commented Jan 10, 2012 at 14:21
  • 3
    @NonameNoname, a MITM capable of inserting this iframe could also have his own server responding to http://secure.example.com/ (at least enough to capture the cookie), even if the genuine server has nothing listening on port 80.
    – Bruno
    Commented Jan 10, 2012 at 19:47
  • If you use HTTPS Everywhere, or define the domain as HTTPS-only in NoScript, or as (possibly user defined) HSTS in Google Chrome... then your HTTP cookies are safer than "secure" cookies, as the cookie key namespace is not longer shared between the different schemes (https:, http:).
    – curiousguy
    Commented Jun 28, 2012 at 13:25
  • If there's a proxy in the mix, the the browser will send the request regardless if secure.example.com is available or not. Inventing elaborate client side configurations does not help the majority of users - and is semanatically different from the secure flag.
    – symcbean
    Commented Jul 3, 2012 at 10:28

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.

Original article

  • If you use HTTPS Everywhere, or define the domain as HTTPS-only in NoScript, or as (possibly user defined) HSTS in Google Chrome... at least you are not vulnerable from the HTTP side.
    – curiousguy
    Commented Jun 28, 2012 at 13:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .