CSRF Countermeasures

Question

I'm working through a book on web application security and it says that an effective CSRF countermeasure is to assign a temporary pseudo-random token to sensitive actions performed by authenticated users- and that secret tokens should last only a short time and be unpredictable in order to be effective.

My question is what is the range of security if the token is the UID set via the user database? Presumably if I've done my job properly then no one will know what their UID is and there's no way that it could be found, either.

Answer 1

CSRF tokens have two parts - one part is generally set as a part of the hidden form fields, which aren't that hard to find.

Phrased differently, CSRF tokens are stored both client-side and server-side. Anything stored client-side, you have to assume could be found/read/extracted. (Assume it can be compromised.)

So it's it's impossible to ensure no one will know what their UID is. This is why it should change frequently (as close to "on each request" as possible).

Related: https://stackoverflow.com/questions/1805838/csrf-token-generation

Good resource: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

You didn't mention your platform. (.NET, Java, PHP, etc). Many platforms have well-defined libraries for dealing with this. I'd strongly recommend using one of those if possible.

Answer 2

Unguessable UID are hard... Remember that the attacker can often afford to be patient, so he can make a lot of attempts with various potential UID values. In order to make UID truly unguessable by the attacker, you would have to generate them at random in a large enough space: this means using a cryptographically strong PRNG (your server already has one, called /dev/urandom on Unix-like systems, or CryptGenRandom() on Windows) and making the UID large enough so that the attacker will not hit one "by chance" (so it would have to be, at a minimum, 12-byte long, preferably more).

Unless you use such fat, random UID, you cannot rely on UID being unknown to the attacker.

Another point, which others have made, is that the CSRF token is, by nature, a piece of data which is sent by the client along with his request (the request will be accepted by virtue of coming with that token). Therefore, if the UID is the CSRF token, then it has gone through the client... at which point, we can only assume that the attacker got a copy of it. This is the whole idea behind the concept of "secret tokens should last only a short time": to make the life harder for the attacker, by shortening the time window during which a grabbed secret token can be used. The UID is long-lived, thus not appropriate in that role.

Answer 3

As already mentioned, the UID will be sent as part of the HTTP request. This can easily be seen either looking at the raw HTTP traffic using a network sniffer like wireshark or using a HTTP proxy (burp).

If a user discovers the UID it may be posible to derive the UID for other users and subvert the CSRF protection.

Use a random (not static UID) on each request and verify this in the server-side component (controller and likewise).