23

I understand that cookies with the secure flag should be transmitted over a HTTPS connection. It also means that these cookies should be protected from adversaries (private cookie). Thus, it is important to set the HttpOnly flag on this kind of private cookie to prevent XSS.

Is a private cookie with the secure flag but no HttpOnly flag a problem?

Essentially, I think the HttpOnly flag should be added to a cookie with the secure flag.

Anders
  • 64,406
  • 24
  • 178
  • 215
HyunJae Nam
  • 441
  • 1
  • 3
  • 8

4 Answers4

27

The secure flag ensures that the setting and transmitting of a cookie is only done in a secure manner (i.e. https). If there is an option for http, secure flag should prevent transmission of that cookie. Therefore, a missing secure flag becomes an issue if there is an option to use or fall back to http.

httpOnly ensures that scripting languages (ie. javascript) won't be able to get the cookie value (such as through document.cookie). The only way to get it is through http request and response headers. Therefore, a missing httpOnly coupled with XSS vulnerability is a recipe for stolen session token.

It's best to put httpOnly and secure flag for your session token. Other cookies, it would depend on how sensitive it is and what is it used for.

Jonas
  • 5,063
  • 7
  • 32
  • 35
Link
  • 496
  • 4
  • 7
  • 1
    indeed and upvoted. Just a small observation about the less sensitive cookies : why not securely flag them all, regardless of their sensitivity ? I don't believe adding the 2 headers consume resources and this mitigates the risk of a wrong sensitivity assessment. 2 cents :) – niilzon Apr 11 '17 at 07:23
  • 1
    The `Secure` flag indeed ensures that the cookie is only transmitted over a HTTPS connection, but it can still be set by a HTTP web site. [Cookie prefixes](http://www.sjoerdlangkemper.nl/2017/02/09/cookie-prefixes/) are meant to solve that. – Sjoerd Apr 11 '17 at 07:26
21

These two flags mitigate two completely different attack vectors.

  • HttpOnly - mitigates successful Cross-Site Scripting attacks.
  • Secure - mitigates against Man-In-The-Middle attacks.

One without the other means you've only mitigated that particular vector. That is, it depends what threats you are defending against. HttpOnly is still useful even if Secure is not set, because a Man-In-The-Middle also needs to be suitably placed - for example, on the local network. A cross-site scripting attacker could be located anywhere on the internet, so mitigating this in itself is still useful.

As a note, these flags should be "defence-in-depth" measures only. I'd recommend HSTS over the Secure flag, and a tight Content Security Policy with proper output encoding over HttpOnly flags any day, however if your system is already built adding them later can be prohibitive.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
4

HTTPonly cookie flag acts as a security control for session cookies as it prevents client side scripts from accessing the cookie value. This is effective in case an attacker manages to inject malicious scripts in a legitimate HTML page. The HTTPonly flag will prevent the malicious script from accessing the session cookie hence preventing session hijacking.

Note that this flag only reduces the risk to a certain level and if there is a script injection vulnerability present, it can still be exploited in multiple ways as discussed here

Shurmajee
  • 7,285
  • 5
  • 27
  • 59
2

The "httponly" flag prevents from accessing this cookie through client side scripts (JS, TS) on browser. If you will have an XSS vulnerablity on your page the attacker will not be able to access the "document.cookie" variable.

So answering your question - Yes. This can be a problem.

Page protected with SSL do not protect against possible XSS attacks and gives opportunity to the attacker to get this kind of cookie.

Bartosz Rosa
  • 337
  • 1
  • 6