JavaScript can overwrite or remove HTTPONLY cookies | Hacker News Reader

JavaScript can overwrite or remove HTTPONLY cookies

sjoerdlangkemper.nl

25 pointsEGreg14 comments

Also 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.

Seems like a bug in browsers.

Agreed, 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.

My cofounder wrote about how httponly cookies are pure security theater, a decade ago: https://news.ycombinator.com/item?id=12141611

Yup, 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.

Which 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.

SameSite=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.

You 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.

Indeed. Defense In Depth is the name of the game.

Your cofounder's take is similarly correct to your take about 2016 being a decade ago.

Design 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....

(2020)

Did something get changed since 2020?

It'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

Reply on news.ycombinator.com