0

To prevent cross-site request forgery attacks, I'm considering the following scheme:

For each user, store a random key. If the user submits any "dangerous" information, include a security token and a creation date in the upload. If the creation date older than T (I'm currently leaning 5 minutes), the request is considered expired and invalid.

The security token will be a MAC (Poly1305-AES ?) over the creation date, signed with the random key of the user. If the request is young enough, check if the MAC is valid for the datetime for this user. If it is, consider the request authentic.

Is this scheme secure against CSRF and replay attacks, provided all communication will be over https?

Martijn
  • 103
  • 2

2 Answers2

2

CSRF is a solved problem. See CSRF Prevention Cheat Sheet on owasp.

valentinas
  • 1,038
  • 8
  • 10
2

Your approach seems like a valid implementation of CSRF measures: using a token that is submitted outside of the cookie mechanism.

Things to consider with your approach:

  • Make sure the random key for each user is generated using a cryptographically secure method.
  • By "dangerous" input I'm assuming you mean all POST requests - if so that is the correct approach as long as you have no GET requests that alter data (which is usually not a good approach in itself).
  • I would have a unique key based on user session rather than a date in the last five minutes. You would be best off using a hash of the session ID and user key rather than involving the date, which will make things a little more secure and less likely for a user's key to be discovered if an attacker had access to another user account for a period prior to any attack.
  • I would not try and make a CSRF token protect against replay attacks - this is not its job. HTTPS will protect you against this.

Also check out the Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet.

Community
  • 1
SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • Thanks! That's indeed roughly what I mean with "dangerous". Non-idempotent would possibly be the nicer description (POST and PUT) though I might in some cases have idempotent operations that hit limits of GET requests, and may abuse a POST for that, in which case it wouldn't need countermeasures. The problem I have with tying things to the session, is that I'd like to be essentially stateless and session-free. The cheat sheet in most cases assumes a session too unfortunately, but the synchronised cookie/hidden form field solution looks good to me too. – Martijn Mar 21 '14 at 13:07
  • @Martijn You could go for an approach like [this one](http://security.stackexchange.com/a/49808/8340). No cookies needed, the Session ID is transmitted in a hidden form field instead and provides protection for CSRF. – SilverlightFox Mar 21 '14 at 14:23