4 ms·
That's a nice summary! I still think allowing cookies to span more than one distinct domain was a mistake. If we had avoided that in the beginning, cookie scop
by Udo 16y ago
That's a nice summary!
I still think allowing cookies to span more than one distinct domain was a mistake. If we had avoided that in the beginning, cookie scope implementations would be dead simple and not much functionality would be lost on the server side. Also, JavaScript cookie manipulation is something we could easily lose for the benefit of every user, web developer and server admin. I postulate there are very few legitimate uses for document.cookie
- deleted 16y ago[deleted]
- tptacek 16y agoThere may be few legitimate uses for document.cookie, but eliminating it does very little to prevent cross-site scripting.
- pak 16y agoHow about double-posting session ID's from the cookie within AJAX requests to prevent XSRF? I've certainly used document.cookie for that. The only other scheme I know of to defend against XSRF is to generate secret values for every request, which is not always practical.
- tptacek 16y agoI'm not sure I can think of one web app I've tested this year that overloaded the session cookie for an XSRF token; it is straightforward to just generate a random token and embed it in the page, and that also gives you fine-grained control over CSRF protection for forms where you want per-render instead of per-session protection. You don't need to generate per-request tokens unless you want to; the token is simply yet another thing you stick into the session store and splash out onto the rendered page. (Also, as my colleague Cory points out: if an attacker can influence the ACTION attribute of the form in any way, you've just coughed up your session token to an attacker in the name of blocking CSRF; is the risk worth the reward?).
- brlewis 16y agoI don't think an attacker can influence my ACTION attribute, but just in case, I use only 4 characters from my session token (1MM combinations). I don't think CSRF tokens are easy to brute-force, so that should be long enough. I don't like keeping per-request state on the server, else I would use random CSRF tokens.
- tptacek 16y agoIt doesn't need to be per-request; it can just be another 128 bit random number, stored in the session, re-used for every request.
- pak 16y agoWell, instead of generating two separate tokens, a simpler solution IMHO is overloading the cookie, and it's what I usually see and use. What are you talking about "if an attacker can influence the ACTION attribute of the form"? If they are running JavaScript in your DOM you are already hosed, they can grab any token you put in your form. There is no sane reason for having ACTION change via request parameters: you would have bigger issues than session stealing. And in any other situation, you should be protected by the browser's cross domain restrictions. I don't understand what you are suggesting.
- mike-cardwell 16y agoYou can use the HttpOnly flag with a cookie to prevent JavaScript being able to access it. Here's a good summary: http://www.owasp.org/index.php/HttpOnly http://www.owasp.org/index.php/HttpOnly If you are serving a cookie, and JavaScript doesn't need to be able to access it, you should set it to be HttpOnly to try and reduce the effects of an XSS.
- tptacek 16y agoIt doesn't seem like Michal is sold on HttpOnly and I definitely am not either; most everything you can do with a stolen cookie, you can also do quickly and silently using a captive browser during an XSS attack.
- mike-cardwell 16y agoTrue. Still, given the option of having it turned on or off, I'll turn it on. If only it makes an attack a little more difficult it's worth using.
- jacquesm 16y agoNo cost, potential benefit. I've had to make harder decisions.
- tptacek 16y agoThe cost is "false sense of security", and believe me, from field work, that is a real cost. A majority of programmer applicants can't solve FizzBuzz, so you're deluded if you think that a good chunk of webdevs don't think "HttpOnly fixes XSS". The potential benefit is... what, exactly?
- Udo 16y agoIt lessens your potential attack surface and comes at no cost. And as security-ignorant devs are concerned (which we all are from time to time) it doesn't magically fix vulnerabilities, but it can alleviate the magnitude of exploits. It's a good idea.
- kls 16y agoAlso, JavaScript cookie manipulation is something we could easily lose for the benefit of every user, web developer and server admin With more and more apps moving to pure JS / CSS/ and HTML front ends the lack of being able to manipulate cookies would kill a good deal of in app storage abilities. Eliminating useful feature to make someone else's job easier is rarely ever a good solution.