Hacker News new | past | comments | ask | show | jobs | submit login

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




I'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?).


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


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


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: