Comment by zoomzoom | Hacker News Reader

Comment by zoomzoom | Hacker News Reader

The overall gist here seems to be that XSS is not anything to worry about because if there was an exploit the attacker will always choose CSRF. However, there are well-understood and proven mitigation strategies for almost all versions of CSRF attacks. For XSS you are reliant on a CDN or your own code review of your hosted JS to prevent all XSS. I'm not willing to bet I'll never make a mistake like that. An XSS can expose a lot of users very quickly in that scenario, and the mitigating factor usually offered is some time-expiring attribute of the tokens stored locally, but for usability reasons such expiration is usually long enough that an attacker will have plenty of time to use the tokens. Http-only secure cookies provide strong mitigation here that covers more scenarios.

In general, it's annoying because local/session storage are so close to being ready for prime-time, and as outlined here there are various advantages. But the XSS mitigations are too important to abandon if you really want the most security available, IMO.

No, that's not the overall gist. What he's saying is HttpOnly mitigates only a subset of the exploits for Javascript injection attacks, and does nothing to mitigate the vulnerability. Attackers don't "choose" CSRF over XSS; Javascript injection vulnerabilities create new CSRF-like exploits even when the session cookie is "protected" by HttpOnly.

Generally, you can take anything Portswigger says about web security to the bank.

HTTPOnly is security theater!!

It is worse than useless because it makes you think you are secure.

XSS attackers are more likely to generate arbitrary requests to secure endpoints as you via JS than they are to send the cookie to themselves at 3AM so they can rush to craft requests.

And httponly does didly squat to prevent that.

Better is to focus entirely on santizing your output properly in the context it is outputted. And use whitelists, never blacklists.

Hopefully it's clear that I agree with this.

    And use whitelists, never blacklists.

Why?

Blacklists are default allow (if unknown, allow). Whitelists are default block. Default block prevents unknown inputs from causing harm.

I guess, then, that the gist of this debate is:

- If you get attacked in a way where the XSS would allow token exfiltration but are protected by HttpOnly, then the attacker is more likely to just grab data with your session cookie auth and POST that data over to their server using JS (or some other super-CSRF-like attack), so the HttpOnly limited the data you can protect to the token, which hardly matters at that point.

Is that a more fair understanding of the issue? Thanks for the correction here!

Yes, it's better. Condensed: the distinction he's making is between losing your root password and losing a shell running at uid 0.

This is a good comparsion. :)

Reply on news.ycombinator.com