3 ms·
JavaScript can overwrite or remove HTTPONLY cookies
- chromoblob 3y agoSeems like a bug in browsers.
- TechBro8615 3y agoAgreed, although I'd classify it as a design flaw more than a bug. I think the correct design of the overwrite behavior would be to only evict cookies of the same HttpOnly value when a new cookie is set that causes the number to overflow. If that's not possible, then it should throw an error.
- EGreg 3y agoMy cofounder wrote about how httponly cookies are pure security theater, a decade ago: https://news.ycombinator.com/item?id=12141611 https://news.ycombinator.com/item?id=12141611
- Sohcahtoa82 3y agoYup, this is something that is frequently not talked about. HttpOnly merely prevents the theft of the cookie via XSS. It doesn't prevent an attacker from performing operations on behalf of the user via XSS. That said, it does make the attack slightly harder. You have to write a bespoke attack script, rather than just a nearly universal one-liner to steal the cookie and then take over from there. In addition, if the victim navigates away from the page, then the attack ends. Of course, most likely, the attack script will only need a few seconds at most to complete the attack script.
- ttfkam 3y agoWhich is why you'd use HttpOnly along with the SameSite=Strict and Secure attributes. This would prevent an attacker from both sniffing and performing operations on behalf of the user via XSS.
- Sohcahtoa82 3y agoSameSite=Strict only prevents CSRF. Secure only means it goes over TLS/SSL only. If the site has XSS, an attacker can still perform operations on behalf of the user even with SameSite and Secure.
- ttfkam 3y agoYou are correct. I was thinking CSRF. XSS is why Content Security Policy exists. script-src 'self' There are no silver bullets, but together, they are greater than the sum of their parts.
- Sohcahtoa82 3y agoIndeed. Defense In Depth is the name of the game.
- cjbprime 3y agoYour cofounder's take is similarly correct to your take about 2016 being a decade ago.
- chromoblob 3y agoDesign flaw would be if the specification implied that manipulation of cookies through non-HTTP APIs could affect the HttpOnly cookies. But it only says: "the attribute instructs the user agent to omit the cookie when providing access to cookies via "non-HTTP" APIs". So, the browsers really should "omit" it, that is, not affect it directly by scripted manipulation of cookies in any way. Yes, "omit the cookie" feels a little vague, but I'm also not sure that the specification authors should be blamed for this wording. https://datatracker.ietf.org/doc/html/rfc6265#section-4.1.2.6 https://datatracker.ietf.org/doc/html/rfc6265#section-4.1.2....
- EGreg 3y agoAlso notice that you in most implementations where clients can choose their own value for sessionId, malicious injected scripts can use a session fixation attack to then exfiltrate your info. They don’t need to craft a special link, as long as they inject a script into your site it’s game over. That’s why your server should sign session IDs it generates with an HMAC and reject any ones that the client simply sets! The client can overwrite httponly but it will only log the user out and annoy them.
- lapcat 3y ago(2020)
- EGreg 3y agoDid something get changed since 2020?
- lapcat 3y agoIt's standard practice on Hacker News to put the year in parentheses at the end of the title if the submission is from not the current year. For example: https://news.ycombinator.com/item?id=36832999 https://news.ycombinator.com/item?id=36832999