Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I was just going through the OWASP's Cheat Sheet for CSRF Prevention. In the Double Submit Cookies method, I saw this

the site should generate a (cryptographically strong) pseudorandom value

This method completely relies on the fact that Cookie/Header can not be injected by the attacker.

An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy.

Then, why should the pseudo random value be cryptographically strong?

share|improve this question
add comment

2 Answers

up vote 15 down vote accepted

Short answer: To prevent brute forcing the CSRF token.

Let's take a trivial example: let's say your token is a single digit, accepting values from 0 to 9.
Now sure, an attacker cannot read this value from the cookie or header, but she does not have to - she can just have the attack send 10 CSRF requests, one with each possible value. One of them will be correct.

Using a cryptographically strong random value will prevent this, and can prevent the attacker from trying to scale up this attack (by having the attack send e.g. 1000 requests instead of 10, or 10,000, or... )

share|improve this answer
    
Can't we just counter this, by increasing the number of bits? –  thefourtheye Dec 18 '13 at 13:06
3  
@thefourtheye: At issue is predictability. A cryptographically strong random value cannot be predicted (which is why it is cryptographically strong). Sure, you can generate a 64-bit number, but if the attacker can predict the numbers you generate (or can narrow down the possible numbers to a brute-forceable range) then the extra bits add no extra security. –  Martijn Pieters Dec 18 '13 at 13:18
    
@MartijnPieters Yup. I agree that. But, increasing the number of bits will make the token difficult to predict, right? –  thefourtheye Dec 18 '13 at 13:20
3  
@thefourtheye: 1 << 63 + randrange(10) is 64 bits, but just as easy to predict as the example in this answer. So no, it depends on how the bits are generated. If you do it properly, you have a cryptographically strong random number anyway. –  Martijn Pieters Dec 18 '13 at 13:22
1  
@thefourtheye: Yes, see Is a rand from /dev/urandom secure for a login key? –  Martijn Pieters Dec 18 '13 at 13:25
show 9 more comments

It doesn't

It just has to be pseudo random.

CSRF is not compatible with brute force attacks. Consider the attack vector:

  1. Malicious user crafts a special email or web page with HTML that posts to the site of interest
  2. User is logged on to the site of interest, and the session ID is passed passively (it's a cookie)
  3. User is tricked into clicking the link in the specially crafted email or web page
  4. Link "forges" the request. The link doesn't have to contain the session ID because it's in the cookie. And it doesn't have to pass the CSRF token found in the header (it's passed passively-- it's a cookie). But it does have to contain the CSRF token in the form post.

There is no way a hacker is going to trick anyone into clicking a link hundreds of times. Even if it's a script that sends a ton of requests on a single click (assuming the hacker has figure out how to do that-- browsers don't allow cross-domain AJAX requests, so we're probably talking about a page containing hundreds of clear GIFS or something else totally whacky), it's not going to be able to get through a whole lot of search space without timing out.

Also, there is no way for the attacker to determine if the attack worked for a particular value-- it's a "fire and forget" attack.

So the idea that the CSRF token can be brute forced is far fetched at best. The hacker would have to be personally logged on-- which is a different attack entirely.

The only reason you need any entropy at all really is because CSRF attacks tend to be delivered via spam. Let's say you're an idiot and your CSRF token only has 16 bits of entropy, and the hacker sent out 65,536 spam emails with the exact same token. 65536/2^16 = one of those attacks would actually succeed. Assuming 0% of the emails hit spam filters, 100% of the users opened them, and 100% of the users happened to be logged into your app at the moment they clicked the evil link.

Other than hoping to sucker in a ton of users, there's no way for a hacker to scale the attack large enough to call it a brute force attack with any significance to it.

share|improve this answer
1  
Actually, this is wrong, on several key points. Brute force IS possible, just not at the level to crack 32 (or even 16) bytes of entropy. And while browsers do not allow cross domain AJAX requests, they DO allow cross domain POST requests - aka submitting a form (which is easy to do silently in javascript). Alternatively, that "page containing hundreds of clear GIFS" (or rather 1x1 pixel, at the very bottom of the page far below the break) is not so "wacky", and in fact HAS been seen in the wild. So yeah, if the CSRF token space is small enough, or predictable enough, it CAN be brute forced. –  AviD Dec 19 '13 at 8:31
1  
That is why CRNG is required, to ensure that it is not predictable, as I explained in my answer. Remember, the CSRF attacker does NOT need to "trick" you into clicking a link, the CSRF requests can be sent out silently - either via POST requests in javascript or "hidden" IMG tags. –  AviD Dec 19 '13 at 8:34
    
Yes it is "easy enough" to submit a form silently in Javascript-- but only one (see here). Maybe two if you work really hard (see here). It is impossible to submit 2^16 forms. More importantly, the hacker has absolutely no control over timing-- the user will open the page at his leisure. Arguing about 64 bits of entropy and/or "true" unpredictability is absurd when you understand the attack vector. –  John Wu Dec 19 '13 at 15:13
    
Huh what? It is trivial to submit multiple standard POST requests via javascript. I don't understand the confusion in those links, and the SO question is not exactly the same thing you're referring to here. I agree that 2^16 bits of entropy would be too difficult to brute force in this way, but 10 / 100 / 2^8 is easily within realm of feasible. I am not sure what part of the attack vector you're misunderstanding. –  AviD Dec 19 '13 at 15:25
    
Perhaps we agree then. In my answer above I state you'd have to be an idiot to use 16 bits (or less) of entropy. –  John Wu Dec 19 '13 at 15:32
show 6 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.