How about preventing CSRF this way?

Question

According to Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet , the recommended solution to protect web site from CSRF attacking is to implement Synchronizer Token Pattern. And This requires the token to be random or unique.

And recently, we are trying to apply this to our web site. And one of my colleges wants to generate the token by encrypting the current sign-in user's id concatenating a timestamps with a safely kept password. And then append the token into the form.

When user sign in, we set a logged-in user id cookie under our site domain and the root path /. So if we can find this special cookie, then we get the logged-in user's id.

When we get the token, we try to decrypt it to get an user id and an timestamps. We then compare the user id with the current sign-in user's id and use the timestamps to check if the token timeouts.

So I want to know if this works and what's the pros and cons?

The reason why we try to do this is that we try to avoid sessions. Some frameworks like Struts2 have build-in implementations based on sessions.

Answer 1

This is probably a bad mechanism, since it violates Kerckhoff's principle. If an attacker knows how your "encryption" works, he can just encrypt his own CSRF blob for a specific user and use it in targeted attacks.

CSRF leverages the fact that your browser will send a cookie containing a session ID that authenticates you to the server, even if the request is generated by an automated script. In order to protect yourself against this, you just need to require a token that is unknown to an attacker, and that is not automatically sent by the browser without direct instruction. The standard way to do this is to generate a random value, known as a CSRF token, and add it to the parameters of a POST request. As long as the target script verifies the CSRF token somehow, you're protected.

The simplest way to do this is to generate a random CSRF token when the session starts, and store it as a session variable. It can then be injected into forms that require CSRF protection, and checked by the target script.

Adding any "extras" to this scheme, like encryption / timestamps is snakeoil - i.e. it provides no real security and complicates the scheme, which results in a potentially greater attack surface. Remember: don't be a Dave!