Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm writing a library to generate and check CSRF tokens.

I would like to do it without having to use sessions and/or cookies. What I've come up with is this:

  1. A token generated from the current time and a unique token id (unix-timestamp.unique-token-id).

  2. The token would then be hashed using the HMAC method. The returned value would be: hmac-hash.unix-timestamp.unique-token-id. This could then be hidden in a form.

  3. The library would then test the returned token by extracting the HAMC hash, time and unique token id from it and then compare the returned HAMC hash to one generated using the returned time and unique token id.

As long as the HMAC secret on the server stays secret it should be secure or did I missed something?

share|improve this question
    
I'm not sure if this is better for SO or here –  TheLQ Feb 26 '11 at 17:25
add comment

3 Answers

up vote 7 down vote accepted

If the token isn't tied to a particular session or cookie, then I (as an attacker) could write a script to harvest tokens, and embed them in my hosted pages. The token would then be passed by the victim's browser to your site and would validate correctly as it was generated by your server. (even though it's be for the wrong user if that makes sense.)

share|improve this answer
    
Thanks a lot, I knew I was forgoting something. –  Glass Robot Feb 26 '11 at 18:23
add comment

I'll argue with ach_l's answer, because I'm interested in the sessionless CSRF protection too :)

(If the token isn't tied to a particular session or cookie, then I (as an attacker) could write a script to harvest tokens, and embed them in my hosted pages. The token would then be passed by the victim's browser to your site and would validate correctly as it was generated by your server.)

If the tokens are signed with the "very secret key" and the userid, you might harvest them, but will not be able to use them, as the harvested ones will differ from the actual user's under attack. So even if the session (and sessionid) timeouts (in my case after 15mins), the token is bound to the user and contains a timestamp that can be applied (e.g. after a day or so). Am I missing something?

share|improve this answer
    
Thats what I ended up doing, adding a user_id (i.e. email address, primary key from the users table, etc) to the HMAC hash locking the token to the user. –  Glass Robot Mar 3 '11 at 17:45
    
I'll agree that is a potential solution. I think I had a bit of a mind block on library and thought a filter where you didn't have the userid... And having a sessionless solution would prevent the need for session affinity. –  Charlie Mar 4 '11 at 4:02
add comment

I as an attacker will resubmit the data with the same token within the n seconds. assuming n is the expiary times. This sounds like a replay attack though. However I can change the other data of your form fields while keeping the tokens same. as you have no

share|improve this answer
add comment

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.