client generated double submit cookie, cross site request forgery prevention

views:

152

answers:

client generated double submit cookie, cross site request forgery prevention

in a double-submitted cookie csrf prevention scheme, is it necessary for the server to provide the cookie?

it seems i could have javascript on the clients page generate and set a cookie "anti_csrf", then double submit that (once as a cookie, done by the browser, and once in the body of the request).

a foreign domain would not be able to read or write the "anti_csrf" cookie to include it in the body of a request.

is this secure, or am i overlooking something?

If the user already has the "anti_csrf" cookie set for your domain, then the CSRF attacker is home free! The HTTP request will go out with the cookie, and of course it's easy to include the parameter in the POST if you know what the value is.

The cookie name doesn't have to be a secret, but the cookie value has to be a hard-to-guess secret known only to the user session. That way, the attacker does not know (and cannot guess) what to put in an attacking HTTP transaction.

If you put the code on the page that makes up the cookie value, then you have to assume that the attacker can get his/her own session at your site (that is, a valid "real" login) and examine the code directly. If it's easy to figure out how the cookie value is generated client-side (and, for just about any client-side solution known to man, it will be), then again the attacker can have their attacking page include the right parameter value in an attack POST.

Pointy 2010-04-01 15:39:09

you mean "That way, the attackeR does not know"?

dalbaeb 2010-04-01 15:48:21

yes; crap I thought I fixed that ! Thanks @dalbaeb

Pointy 2010-04-01 15:57:08

the "anti_csrf" cookie value will be set as a random N character string. i don't think there's a realistic possibility of an attacker guessing that?

james 2010-04-01 16:08:24

Are you using a cryptographically-secure random number generator? If you're not a security expert (and I'm certainly not), don't try to make judgements about how secure something is. It may be surprisingly easy for the attacker to learn something about the client's random number generation. Remember, they'll have your source code!

Pointy 2010-04-01 17:16:50

A cryptographically secure random number generator means that it is hard to guess the next value even if you know the last n values. That does not apply here. Any RNG with a large range and a distribution reasonably close to uniform makes guessing infeasible.

Tgr 2010-05-08 19:15:10

That's not necessarily true, and the degree to which you'd want to rely on a regular RNG should be proportional to the value of the information you need to protect. Remember that it's always wise to assume that the attacker has all the source code, and knows how your servers are configured, and knows where your RNG gets its seed.

Pointy 2010-05-08 19:23:35

Since we are talking about javascript, the random number will be generated on the client's side.

Tgr 2010-05-08 21:40:45

No, the random number is not necessarily a client-side generated value. We have to presume that the attacker cannot issue a GET under the auspices of the victim's session cookie and read the results. Thus, the server can prepare the secure tokens to be included in form results. The attacker can prepare a form and POST it with the benefit of the victim's session cookie, but the synthesized "attack form" won't contain the proper token.

Pointy 2010-05-08 22:23:06

The random number will be generated with `Math.random` (otherwise what would be the point of doing it in javascript?) and that takes its randomness from the client, so the attacker has very limited access to it. (Though if you are paranoid, you can probably use something like [jsCrypto](http://crypto.stanford.edu/sjcl/) instead.) Anyway, generating the cookie at the client is usually a bad idea, because it will make you javascript-dependent. Not only will that hurt accessibility, it means that errors in your scripts (possibly in unrelated ones) render your site unusable.

Tgr 2010-05-09 10:00:45

On the first glance it seems safe, but it will mean users without javascript cannot use your forms.

Tgr 2010-05-08 19:13:06

Tgr, read this:

http://jazzy.id.au/default/2010/09/20/cracking_random_number_generators_part_1.html

All the attacker needs is to get a token or two out of the random number generator, and then they can predict every subsequent and every previous random number if it's not cryptographically secure. If the random number generation is done client side in Javascript, I don't know of a single browser that uses a cryptographically secure random number generator, so they simply have to call Math.random() a few times and they can work out what token was generated for your cookie.

2010-10-18 23:29:19

ansaurus

tags:

views:

answers:

client generated double submit cookie, cross site request forgery prevention

related questions