2

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?

Improve this question
1
  • I'm not sure if this is better for SO or here
    – TheLQ
    Feb 26, 2011 at 17:25

3 Answers 3

Reset to default
8

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.)

Improve this answer
0
3

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?

Improve this answer
2
  • 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, 2011 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, 2011 at 4:02
0

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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