Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

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
add comment

2 Answers

up vote 2 down vote accepted

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

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 secure.example.com doesnt work, the port 80 is closed. –  Novice User Jan 10 '12 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 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 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 Jul 3 '12 at 10:28
add comment

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
add comment

Your Answer

 
discard

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.