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 steal a non secure Cookie (Secure Flag is false) when the Web Server (IIS) only allows Https?

share|improve this question
    
can't comment, sry: youtube.com/watch?v=0fRk-wL0AQ0 please post this as comment :) –  gasko peter Dec 20 '13 at 11:07
add comment

2 Answers

up vote 9 down vote accepted

Of course it is possible...

Think about it this way:

  • The secure flag ensures that the cookie is locked to HTTPS.
  • HTTPS ensures that the connection with the server (requests + responses) is tied to the server's certificate.
  • The server's certificate ensures the actual identity of the web server.

Now, if you remove that first step, the cookie obviously can be sent in an HTTP request...
Which can be sent to a different server....
Which is impersonating your web server.

There are many forms of attack (e.g. DNS spoofing) that would cause you to connect with the wrong server, and of course HTTPS (using TLS/SSL) mitigates that quite well.
Even if your actual application IS using HTTPS, there is no guarantee that the bogus server is, right?


But let's not stop there, there is an even more trivial scenario.

You say that your web server only allows HTTPS.
That is, it will only accept requests that are HTTPS, and it will reject outright any HTTP requests.
But that HTTP request was already sent in the clear.

If an attacker - or even just a careless programmer - can cause just a single request to be sent from the user's browser over HTTP, then that cookie WILL be sent. Over HTTP. In the clear. With no encryption. (I have actually seen this quite a bit in the wild, the 2nd type more than the 1st...)

Often, that is all that is needed.

Do yourself (and your users) a favor, always enforce HTTPS at all levels.

share|improve this answer
    
plus man in the middle can always be used... especially with weak https encryption –  cengizUzun Dec 20 '13 at 12:43
    
@cengizUzun sure, that's a subset of the bogus server. HTTPS should prevent that, lacking HTTPS effectively allows it. –  AviD Dec 20 '13 at 12:56
    
that's why i mentioned weak encrytions... Is it easy? no. Is it possible? Yes. I sometimes still see 56k enc. allowed... –  cengizUzun Dec 20 '13 at 13:03
    
It depends what you mean by rejects HTTP. If the site listens on port 80, but the listener bounces you up to HTTPS or denies you access, then yes, the cookie was sent in the clear. But if nothing was listening on port 80 (and nobody was actively impersonating you or someone is forcing you to choose a different port like in Thomas' example below), then the TCP connection will never be established, and the unsecured cookie will not be sent in the clear. –  Matt Dec 23 '13 at 0:24
    
@Matt that is correct, I did not get into the low-level TCP details, but what you say is (usually) correct. I say usually, because there are some real world cases that confuse matter - for example, a reverse proxy that IS listening on 80, even though the webserver is NOT. And that is besides all the many webservers and configurations that block HTTP at the webserver level, after receiving the incoming connection, or as you say, redirect the user to HTTPS. –  AviD Dec 23 '13 at 0:46
add comment

The core point is that though the server only accepts HTTPS, the client does not know it. The human user might, but not the software client.

Suppose the following setup:

  • The HTTPS-only server is https://www.bank.com/.
  • You are the victim.
  • The attacker can eavesdrop (passively) on your traffic.
  • The attacker knows a Web forum that you occasionally read.

Then the attacker just has to include in the Web forum the following HTML excerpt:

<img src="http://www.bank.com:443/foo.png" />

Just that. When your browser sees that, it will open a TCP connection to www.bank.com on port 443; that connection will work, because www.bank.com actually expects incoming connections on port 443. Of course, the bank will then want to "talk SSL", but at the TCP level, the connection succeeds (SYN, ACK+SYN, ACK).

Then your browser sends an HTTP GET request over the connection. That request will include the cookie, in plain view, since the target is www.bank.com and the cookie was not marked as "secure". Of course, the server will reject the attempt because it expects a SSL ClientHello message, not HTTP; however, that's too late, the cookie has already traveled before the prying eyes of the attacker.

(Variants of the attacks include a more active attacker with, e.g., DNS spoofing to impersonate a fake www.bank.com, but the same principle remains: since the browser does not know that the server will do only HTTPS, it will gleefully send the cookie over plain HTTP.)

share|improve this answer
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.