153

EDIT

What one means by "a secure cookie" is ambiguous. To clarify:

  1. Secure as in sent over the https:// protocol — ie. cookie is not sent in plaintext. Known as the "secure flag"

  2. Secure as in the cookie cannot be read by Javascript running in the browser — ie. document.cookie will not work. Known as the "HttpOnly" flag.

This edit is to clarify that the original question is asking about the 2nd case.

Original Question

Is there any way to read a secure cookie with JavaScript?
I tried to do it using document.cookie and as far as I can see on this article about secure cookies and HttpOnly flag, I cannot access a secure cookie this way.

Can anyone suggest a workaround?

rmcsharry
  • 5,363
  • 6
  • 65
  • 108
tzam
  • 1,802
  • 3
  • 14
  • 15
  • 2
    From [wiki](http://en.wikipedia.org/wiki/HTTP_cookie): A secure cookie is only used when a browser is visiting a server via HTTPS. – Pavel Hodek Nov 09 '11 at 11:39
  • 9
    @Pavel Hodek That's the wrong flag. The "secure" cookie flag has nothing to do with the HTTPOnly security flag. They have an awful naming system. – rook Nov 09 '11 at 18:28
  • 1
    The title of this questions ought to be changed to include the "HttpOnly" flag. As it stands it looks like the question is about the "Secure" flag. – Tom Nov 12 '18 at 14:18

3 Answers3

193

Different Browsers enable different security measures when the HTTPOnly flag is set. For instance Opera and Safari do not prevent javascript from writing to the cookie. However, reading is always forbidden on the latest version of all major browsers.

But more importantly why do you want to read an HTTPOnly cookie? If you are a developer, then disable the flag - if the value isn't a sensitive value like an authentication token then it doesn't need to have this security flag enabled. The HTTPOnly security precaution is to help defend against XSS, but even with this flag enabled you need to still test your code for XSS vulnerabilities because this class of bugs are still fully exploitable. I recommend avoiding disabling security features, but sometimes the HTTPOnly flag gets in the way of application behavior, and if it isn't an authentication token or personal information (PII) then it likely doesn't need this flag.

If you are an attacker, then you want to hijack a session. But there is an easy way to hijack a session, even when the HTTPOnly flag is enabled. You can still ride on the session without knowing the session id which is how the The MySpace Samy worm spread. This worm used an XHR to read a CSRF token and then perform an authorized task of posting itself to your wall - thus infecting everyone on your feed. In a session riding attack, the attacker can do almost anything that the logged user could do - even without access to the session id stored as a cookie value.

People have too much faith in the HTTPOnly flag, XSS can still be exploitable. You should setup barriers around sensitive features. Such as the change password filed should always require the current password. Requiring a 2fa step for sensitive administrative features can make it more difficult for an attacker to access using stolen credentials or via CSRF aka "session riding" attacks.

While adding a CAPTCHA can make CSRF more difficult, if the attacker has XSS they will be able to bypass a CAPTCHA challenge response by using a BeEF proxy to view and then bypass the CAPTCHA. A Same-Origin Policy bypass maybe used to view a CAPTCHA's challenge response (or a CSRF token), a good example is Universal-Cross-Site-Scripting or UXSS. Requiring 2fa raises the bar over a CAPTCHA, as it would still require additional human interaction and that introduces another opportunity for the session-riding attack to be discovered and stopped.

rook
  • 66,304
  • 38
  • 162
  • 239
  • Could you please elaborate on the worm thing? That link doesn't work and didn't really understand much from the internet as well. Thank you. – Abhishek J May 12 '17 at 13:22
  • @Abhishek Jebaraj If you don't understand the sammy worm, or CSRF tokens, then try first understanding the limits of the [same-origin policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy) – rook May 12 '17 at 17:03
  • 1
    i want to get the expiry date of an http only cookie, how do I do that – PirateApp Oct 31 '20 at 15:56
  • 1
    @PirateApp The approach I've used is to generate a non-HttpOnly cookie that contains just the timeout value at the same time as the HttpOnly cookie. You can then check the timestamp from the 2nd cookie while leaving sensitive info in the HttpOnly cookie. – bingles Aug 26 '22 at 18:25
  • 1
    "_But more importantly **why** do you want to read an `HTTPOnly` cookie? ... If you are an attacker, then you want to **hijack a session**. But there is an easy way to hijack a session despite the `HTTPOnly` flag. ... People have too much faith in the `HTTPOnly` flag_" **BUT THEN ALSO** "_I recommend that you avoid disabling this [`HTTPOnly`] flag if at all possible. The `HTTPOnly` flag... should always be set._" Okay, there's nothing _wrong_ with setting it, but what's the practical, non-cargo culting argument for doing so? What do you lose if anyone that far in would session ride anyhow? – ruffin Dec 06 '22 at 22:20
  • 1
    @ruffin stealing a session ID is worse than a CSRF token, it raises the bar. Sure the bar isn't high enough to prevent getting hacked, but sometimes the session id is a JWT that can be used cross-application, so the splash zone from one XSS could run deep. – rook Dec 07 '22 at 17:42
  • The last edit removed the advice to use `captcha`, but using `captcha` is a viable options instead of always requiring `2fa` – Washington Guedes Mar 29 '23 at 14:51
  • 1
    @Washington Guedes although a CAPTCHA makes session riding more difficult, it is not a suitable defense against XSS-assisted session riding as a BeEF proxy could be used to view the challenge response, i have updated my answer for clarity. – rook Apr 06 '23 at 16:06
76

The whole point of HttpOnly cookies is that they can't be accessed by JavaScript.

The only way (except for exploiting browser bugs) for your script to read them is to have a cooperating script on the server that will read the cookie value and echo it back as part of the response content. But if you can and would do that, why use HttpOnly cookies in the first place?

Ilmari Karonen
  • 49,047
  • 9
  • 93
  • 153
  • You might want to test it to know whether the user browser handles HttpOnly for cookies properly before allow the user to use your site from the particular browser. I'm looking for an example which can assure the browser support of HttpOnly flag. MS also advices to do so, but there is no further advice on the how: [Mitigating XSS with HttpOnly](https://msdn.microsoft.com/en-us/library/ms533046.aspx#httponly) – Ursegor Mar 18 '17 at 11:52
  • I found they advice browser version white listing. I might be wrong, but wouldn't it be a convenient way to check the support from javascript instead? Could you suggest any drawbaks on this? – Ursegor Mar 18 '17 at 12:02
6

You can not. Httponly cookies' purpose is being inaccessible by script.

Akin Zeman
  • 447
  • 7
  • 9
  • 2
    What is new or different in your answer than the already existing ones ??? – HDJEMAI Feb 18 '21 at 21:58
  • 7
    Same as the first sentence of previous answer: `The whole point of HttpOnly cookies is that they can't be accessed by JavaScript.` – HDJEMAI Feb 20 '21 at 08:27
  • 3
    @Akin Zeman: No need to use screaming caps. You may want to dive into Nonviolent Communication. – Gogowitsch Aug 03 '21 at 13:16