Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is it possible to capture the cookies used by HTTPS site when cookies don't have secure flag set.

Suppose the site is does not show up, also does not.

Still can there be any way?

share|improve this question
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. – Sachin Kumar Jan 10 '12 at 9:33
@SachinKumar : Thats where the problem lies ..i dont know which other port is open. – Novice User Jan 10 '12 at 9:59
NMAP :) look for ports with HTTP ... – Sachin Kumar Jan 10 '12 at 10:19
nmap only says 443 – Novice User Jan 10 '12 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 Jan 10 '12 at 12:07
up vote 4 down vote accepted


HTTPS prevents MITM attacks. Consider:

1) you visit which drops a cookie on your browser

2) you then visit however a MITM inserts

<div style='visibility:hidden'>
   <iframe src=''></iframe>

3) MITM sniffs your cookie from the request on the iframe

Or even if you (deliberately) navigate from to 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 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).

share|improve this answer
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? – Sachin Kumar Jan 10 '12 at 14:08
symcbean : In this example doesnt work, the port 80 is closed. – Novice User Jan 10 '12 at 14:21
@NonameNoname, a MITM capable of inserting this iframe could also have his own server responding to (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
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 Jun 28 '12 at 13:25
If there's a proxy in the mix, the the browser will send the request regardless if 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 Jul 3 '12 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

share|improve this answer
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 Jun 28 '12 at 13:19

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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