One use of an anti-forgery token is to prevent Cross-Site Request Forgery (CSRF)
ID: 650948 • Letter: O
Question
One use of an anti-forgery token is to prevent Cross-Site Request Forgery (CSRF) attacks. The attacker doesn't need to sniff the wire in order to carry out a CSRF attack. This attack relays on the fact that the HTTP request is predictable, and the defense is to add a secret value such that an attacker cannot forge this request.
In order for each request to be validated the server must keep track of each client's secret. This requires the server to use significant resources to keep track of this state for a large number of clients.
Is there a cryptographic method that can prevent forging of requests that also very efficient?
Explanation / Answer
If you don't want to store the anti-CSRF tokens on the server, for most purposes it is sufficient to simply store the token as an HTTP cookie on the client. The OWASP wiki calls this technique "Double Submit Cookies".
The reason this works is that, in the standard CSRF attack scenarios, the attacker cannot directly read or modify the user's cookies. Indeed, if the user's authentication credentials are also stored in cookies (as is very commonly done in modern web applications), any leak of cookie data already implies a much more fundamental security failure than a mere CSRF attack.
Of course, an attacker might be able to gain (full or partial) access to the user's cookies via an XSS or other injection attack or through session fixation, but this is mostly outside the scope of CSRF prevention and must be addressed by other means. (One exception to this are login CSRF attacks, which can be used to carry out session fixation; the solution there is to ensure that authentication entry points are also protected with anti-CSRF tokens.)
One possible improvement on the basic Double Submit Cookie technique I might suggest would be to let the anti-CSRF token included in the submitted form data be derived from the cookie value using a secure MAC (such as HMAC) with a secret key stored on the server. This has a few advantages over simply using the plain cookie value as the token:
+ Merely learning (or guessing) the cookie will not allow an attacker to mount a CSRF attack, since they won't be able to derive the token from the cookie without knowing the key.
+ Conversely, leaking the token will not allow an attacker to reconstruct the cookie; in particular, this means that the user's normal authentication credentials may be safely used to derive the anti-CSRF token, without need for a separate cookie.
+ By including additional data, such as a form identifier and/or a timestamp, in the MAC input, the token can be made specific to that additional data. This can compartmentalize the attack surface e.g. by ensuring that an attacker who learns the token for one form will not be able to attack another form in the same application, and that they will be able to carry out attacks only for a limited time.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.