Question

Original Question

Is there any way to read a HTTPOnly¹ 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?

---

¹To clarify, there are two types of secure cookies:

1. Secure as in sent over the https:// protocol — i.e. cookie is not sent in plaintext. Known as the "secure flag". The question is not about these cookies.

2. Secure as in the cookie cannot be read by JavaScript running in the
   browser — i.e.
   document.cookie will not work. Known as the "HttpOnly" flag. The question is about these cookies.

Answer 1

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.