-1

Between most strong CSRF protection, there is the form token protection. The question I have about this method, is about usability: if a user opens multiple page containing a form, which use the token, are generated multiple token, but only the last opened page can successful send the form, all the other will give error.

I thought 2 solutions:

  1. Keep a unique token for all the duration of session.
  2. Store all generated tokens in session.

But:

  1. This is the more realistic solution, but is less safe.
  2. This generate a large resource overhead, because a user could open many pages, and I must store all the generated token.

Therefore, how have you solved this question?

PS The website I'm developing, is practically a ecommerce in PHP and although the money transfer will be managed through an external provider (like paypal), I think right give a good safety to my service.

Eghes
  • 177
  • 1
  • 5
  • 18

1 Answers1

2

You don't need to store tokens in the database.

Instead, you should include the same token in a cookie; a cross-site attacker cannot read or set cookies.
As long as the you get the same token in the cookie as the POSTed form, you're safe.

For additional security, you can hash them with a keyed HMAC hash, and verify that hash to make sure that the token came from your server.
You can also make the tokens per-user.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
  • Thanks SLaks for the answer. The token, is already stored in user's session (but I store session data in database). The tokens are random generated strings therefore really impossible to calculate. Therefore what is the utility oh HMAC Hash? Keep a unique per-user token, is less safe than a per-form-showed token, did't you think? "You can also make the tokens per-user" this thought as established, otherwise where is the security? – Eghes Aug 24 '12 at 13:58
  • 1
    @Eghes: A hash wouldn't do much good, but it wouldn't do any harm. By per-user, I mean to include a user ID in the token (hashed to prevent swapping), so that even in the attacker can read or write tokens, he will still need to get that ID. (this would work better with a separate ID or GUID that is not used for anything else) – SLaks Aug 24 '12 at 14:13
  • Ok, thank you. But, in the end, you suggest to use a single token for all the user session? – Eghes Aug 24 '12 at 14:28
  • 1
    @Eghes: Yes; that's OK. (unless you have less-trusted code running in the domain, in which case you have bigger problems) – SLaks Aug 24 '12 at 14:54