I'm going to mostly agree. It's only a meaningful defense against bottom-rung attackers who go after the lowest-hanging of fruit, and if you're susceptible to them, you've probably got bigger problems (in the server-side RCE realm).
And of course, XSS means token-based SSRF/CSRF mitigations are completely toast in the absence of any extra controls (i.e. password re-prompts, CAPTCHAs). Rough and dirty pseudocode PoC for anyone who thinks different:
// Assuming the token is in the HTML form, and tied to the session.
// If it's in a cookie, just skip to $.post():
$.get("/url", {"arg": "value"}, function(data) {
// ... Grep for token ...
$.post("/url", {"arg": tokenGoesHere});
// pwnd
});
Is that a meaningful security gain? Not in the big scheme of things, no. "Not vulnerable to script kiddie tactics" isn't exactly a bragging right.
The proper fix is, of course, to update your code and remove XSS vulnerabilities.
I'd say a case can be made for it with certain very specific preconditions, with the most obvious being for applications where session tokens persist for convenience, perhaps inordinately so. I agree that at least within that browsing instance, you're dead in the water, but it would still be worse if an attacker gains persistent session access on platforms which handle re-authentication in a manner similar to this: https://github.com/reddit/reddit/blob/1619fe1cc138aad3d9c6bc...
(I got credited[1] for that gem two and a half years ago. It looks like the faulty logic is technically still there[2], but I haven't checked at all to see if they've mitigated it further. Their partial mitigation after my constant harassment was to actually implement site-wide HTTPS/HSTS and implement session token blacklisting since their session management logic needs much more work, but I can't find the latter feature in production anymore.)
---
[1] http://www.reddit.com/u/eganist
[2] https://github.com/reddit/reddit/blob/862a7e0fc5142058a88044...
Correct me if this is exploitable. (I haven't done this myself, but I've seen this in a wild).
A server can override this default behavior by including a domain attribute in the Set-cookie instruction but this is pretty uncommon. Cookie scoping (and therefore cross-domain protection) can be managed differently if the default behaviour is not intended and HTTPOnly is not relevant here. HTTPOnly is really only a simple mitigation against the most obvious and trivial Cross-Site Scripting (XSS) exploitation technique (i.e stealing a session token).
He's not saying that XSS protections don't matter because attackers "prefer" CSRF over XSS. They do not.
What he's saying is that pages that are vulnerable to XSS attacks --- or, properly: pages that are vulnerable to Javascript injection and DOM corruption --- open up a wide vista of exploits, and "stealing session tokens" is just the most naive of them.
Many of the more sophisticated exploits for Javascript injection resemble CSRF. But I think it's a little confusing to overload the term that way: Javascript-injectors have more latitude than conventional "blind" CSRF attackers do.
Long story short: once you've lost control of the Javascript on a page in your same-origin, you're almost always toast. Attackers can hijack sessions. That they don't store and retain the token is irrelevant; the token is just an artifact.
I don't know anybody who works full-time in software security who thinks HttpOnly is a meaningful defense, but, if you're out there, chime in and make a case for it. :)