2

Should the cookie secure flag be set on websites which are served only through HTTPS?

The Secure attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS

Let's say the victim connect to https://example.com and there is no http://example.com. How can an attacker have access to the cookie? I mean if he intercepts the traffic the cookie will be encrypted.

Conor Mancone
  • 29,899
  • 13
  • 91
  • 96
Maicake
  • 497
  • 1
  • 3
  • 13

1 Answers1

2

There is no need to set this attribute if the traffic between client and server(s) for the cookie domain will always be end-to-end encrypted. But, can you really be sure that it is?

  • Server misconfiguration might cause plain traffic.
  • While example.com might be fully encrypted, sub.example.com might maybe not, but the cookie might be valid for this domain too.
  • There are attacks like sslstrip which cause a plain connection between client and MITM attacker even if the connection between attacker and server is encrypted.

Thus, in the interest of robustness it is better to set the attribute even if it seems to be unnecessary. See also Knowing a web application is HTTPS only, do HTTP cookie need the secure flag?.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Thanks for the answer. 1) server misconfiguration like? 2) In the sub.example.com case, should the attacker buy the domain first or in your example you suppose that another application is accessible at sub.example.com? 3) I read that to run a sslstrip attack the attacker acts as a proxy between the victim and the server, changing from HTTPS to HTTP. Doesn't this mean that the original website should support also HTTP ? – Maicake Sep 18 '20 at 12:27
  • 1
    @Maicake: 1) like having HTTP open even you believe it's not? For example by using a server as a HTTPS reverse proxy to some intrnal HTTP site but having the HTTP site still accessible from outside? Note that server setups can be really complex and multiple people involved which don't necessarily talk to each other for each change. – Steffen Ullrich Sep 18 '20 at 12:30
  • 1
    @Maicake: 2) This is about subdomains of an existing domain which the attacker usually can't buy. It is typically about some other application running on this subdomain. Again, server setups can be really complex with overlapping or missing responsibilities and several departments involved, don't assume just a simple site. – Steffen Ullrich Sep 18 '20 at 12:32
  • 1
    @Maicake: 3) see [Does sslstrip work only on websites which use both HTTP and HTTPS?](https://security.stackexchange.com/q/183467/37315), [Mitigating SSLStrip by only serving a site over HTTPS?](https://security.stackexchange.com/q/64979/37315). – Steffen Ullrich Sep 18 '20 at 12:35