storing anti-csrf token in cookie

Question

I generate a random anti-csrf token per session and store it in a cookie (with http_only flag set); then add that token to forms (in hidden input field) and links. when receiving a request on the server, i check that the cookie and anti-csrf token field of the form or link exists and the two's values are the same; if not, it is considered a csrf attack and the request rejected with a proper message.

i ask u if this mechanism is safe/sufficient as a minimum? (that is to say, in the absence of security holes in the browser)

attacker can't read or set the cookie of a domain that he doesn't own, so he can't forge a request that has the same token.

Answer 1

You say "session" - do you have a server-side session? If so, why not put the CSRF token in the session instead of a client-side cookie? That's the normal pattern; it prevents an attacker being able to use their own generated CSRF token value against another user in the case where they have cookie fixation.

Another similarly watertight approach not needing an extra cookie, if you don't have server-side storage, is to create a value including the user or session ID and sign it using a MAC (typically HMAC) with a server-side secret. The server can then verify that the token in the form came from the user whose session it is.

attacker can't read or set the cookie of a domain that he doesn't own

Well, probably... usually. Ways that cookie injection tends to happen (other than XSS in which case you already lost much worse):

• browser bugs, outdated "generic domain" tables/rules etc
• vulnerable neighbour domains (eg set cookie on www.example.com from test.example.com)
• allowing your site to be served from an attacker domain (always check the Hostname: is a recognised-good domain name)

These are typically marginal issues but they depend on factors potentially outside your control as an application author. So for security-sensitive systems it's generally a good idea not to rely on your cookies being unfixatable.

Answer 2

Purely as an Anti-CSRF mechanism that sounds reasonable to me. The standard protection is to use a random token in a hidden form field and then check it on submission, so it looks to me that the only difference in your scheme is that instead of holding that token server-side you're comparing it to a token in a cookie. The solution you've come up with sounds rather like the "Double Submit cookies" option from the OWASP Anti-CSRF Cheatsheet

Obviously if there are other issues in your application (e.g. Cross-Site Scripting) you're likely to have problems but then XSS causes all sorts of problems.