Custom CSRF protection mechanism without persisting tokens

Question

I have had this functionality (csrf protection) for quite some time now. The thing I never liked about it is that it saved csrf tokens in the session file. While it may not be a real problem I see it as a pain because eventually tokens may build up so I need to utilize a gc mechanism and keep track of what was issued when and it all just seems too much for me.

So I spent the last couple of days working on improving this "imperfection" and here's what I've come up with. I will not be posting any real code I'll just explain the idea.

When a form is issued, by default a token is generated. The token consists of some data unique to the user, like session id or user id, combined with the current datetime string in format YmdHi. All of this is encrypted using password_hash and I have thought of further obfuscating the hash by swapping parts of it but haven't done that yet.

The validation was kind of tricky and turned out to be quite a disappointment. In order to validate a token I create a loop that hashes the same information about the user with the date and subtracts 1 minute on each iteration. Number of iterations is equal to the amount of minutes the token is valid for, which is not stored in the token therefore all tokens must be valid for the same amount of time, which doesn't seem like a disadvantage to me, yet.

I want to ask you if you see any possible flaws and exploits with this concept.

The only possible problem I see is that tokens are not actually kept by the server so theoretically anyone can assemble a valid token, however I think it's highly unlikely anybody would spend days in collecting tokens and would happen to have a super-computer in their basement to run statistical analysts on, which is again no guarantee that they would be able to crack the encryption.

Anyway I guess I should stop exposing my incompetence and let the smart people decide what's up.

Answer 1

Personally, I've never seen someone roll their own alternative to an industry standard for security and have it turn out as an acceptable solution. One phrase I hear thrown around a lot in the security community is "Don't roll your own".

Reading over what you are doing it seems like you might be too smart for your own good. This seems like a complex solution that could be less secure than just creating a CSRF token. If someone inherits your code their head will likely explode.

I'm not sure sure where you are storing the token you are creating, but if it's in a cookie there is no protection at all. If you are placing your token into a hidden field in the form then you are essentially using a weirdly modified version of double submit cookie CSRF protection.

My advice - don't go down this road. At best it will be more complex and as secure. At worst it will be more complex and won't work.

Answer 2

I also think you may be over thinking/engineering here. It seems to me that your combining session authorisation with CSRF protection. I'm not a PHP programmer, but in all the languages and frameworks I've used, this level of protection is laready available in some form. Your probably better off using an established solution rather than rolling your own.

Most of the solutions I've seen don't generate new tokens for every request, Usually, there is a single token per session and it is stored with session data, so there is no GC issue tow orry about. All the token should really be doing is verifying that the response has come from the same client the form was sent to. It is usually assumed that the session is already authorised. If your concerned about the session authorisation, then you have bigger problems anyway because the attacker could just hijack the session, in which case, they will get a 'legitimate' token when they request the form.

Answer 3

If you want to avoid extra storage in your application's database or session, why not simply use the Double Submit Cookies prevention method.

Here you simply send a cookie value duplicated via another mechanism along with each request, such as inside a hidden form field.

For example, generate a cryptographically secure random value with 32 bits of entropy. Store this value in a cookie named csrftoken and in each form as a hidden field named csrftoken. When each form is submitted you check that the csrftoken sent from both delivery mechanisms match.

Please do not use Session ID for this - the OWASP page recommends using a separate value from Session ID because it affords extra protection against Session ID leakage. Protect your Session ID as much as possible and not exposing it unnecessarily will help maintain secure session management. Remember that you do not have to store this extra token server side. All you are doing functionality wise is checking the POSTed token matches the cookie - it doesn't really matter what value it is to your server. All that matters is that the same value is submitted via cookie as via the form, as an attacker would not know this value and therefore would not be able to submit it themselves.

Note you do not need a separate CSRF token per form. The only way an attacker is going to retrieve a token is through another vulnerability (such as XSS). And if they can perform XSS, they have already defeated this type of CSRF protection. You should however regenerate the token for each new session to prevent any type of persistent brute force against it.

Answer 4

You have seen that there is a problem when you use time as part of the value when you create a hash - time is constantly changing. But there is some utility in using it in a csrf token. The solution to allow for small variations is to not hash the values to get the token but instead use symmetric encryption of a representation of the time along with some other values.

However using sessions is usually more sensible. And if you have 'users', 'passwords' then by definition you have a session and therefore must be doing state management. There is really no reason not to use the session to maintain the csrf tokens.