Given the nature of this threat, the official OWASP documentation defines it with a use case of an attack:
A CSRF attack forces a logged-on victim's browser to send a forged HTTP request, including the victim's session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim's browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
Perhaps one of the most typical cases is the one the documentation exposes as the canonical attack of this kind.
The problem is an application that allows a user to send a request to a bank using plain text, without any cyphering, for instance, http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243.
In this case, an attacker builds another request that will transfer funds from the victim's account to the attacker's account. To make it work, the attacker embeds this code inside a request of a DOM-Based type, which we saw in previous issues, such as an image request or iframe stored on various sites that are under the control of the attacker:
<img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#"width="0" height="0" />
Now, if the potential victim visits any of the attacker's sites while they are already authenticated to example.com, this forged request is going to include the session information of the victim, thus authorizing the attacker's request.
The OWASP recommends:
Preventing CSRF requires the inclusion of an unpredictable token in each HTTP request.
Also, these tokens should be unique per user session.
- You can include them in a hidden field, for example. The value will be sent in the body of the HTTP request, so we don't compromise the process using the URL.
- The URL (or a URL parameter) can also be used. However, as you can imagine, that supposes a higher risk because it can be analyzed.
- Another form of prevention is demanding the user to reauthenticate (something very common in e-commerce transactions) or even demonstrate that it is a human, using a CAPTCHA.
In .NET, we've seen in A2 that our initial demo of ASP.NET will include an attribute called [AntiForgeryToken] for the methods marked with the [HttpPost] attribute.
So, you'll see the methods marked in this manner:
[ValidateAntiForgeryToken]
publicActionResultMethodProtected()
{
// some code
}If you examine the view related to these action methods, you will see the presence of a Razor Helper:
@Html.AntiForgeryToken()
This ensures that the user cannot submit the form from a remote site because they have no way to generate the token (and you can even add a salt to it). That provides enough protection against CSRF attacks.