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?

  • Not against replay attacks (within the TTL for the MAC)
    – CtrlDot
    Commented Mar 20, 2014 at 21:43
  • Do not try to reinvent the solution to this problem, there are too many pitfalls and gotchas. Commented Mar 20, 2014 at 23:58

2 Answers 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.

  • 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
    Commented Mar 21, 2014 at 13:07
  • @Martijn You could go for an approach like this one. No cookies needed, the Session ID is transmitted in a hidden form field instead and provides protection for CSRF. Commented Mar 21, 2014 at 14:23

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .