What is Cross Site Request Forgery (CSRF)?
“A CSRF attack forces a logged-on victim’s browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim’s browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.”
Cross-site scripting (XSS) is widely regarded as one of the most used security issue on the web. Few developers pay much attention to another form of attack that’s equally destructive and potentially far easier to exploit. Your application can be vulnerable to cross-site request forgery (CSRF) attacks not because you the developer did something wrong (as in, failing to encode outputs leads to XSS), but simply because of how the whole Web is designed to work.
How CSRF works
All web application platforms are potentially vulnerable to CSRF, but in this post we’ll focus on ASP.NET MVC. Imagine you have a controller class as follows:
public class UserProfileController : Controller
{
public ViewResult Edit() { return View(); }
public ViewResult SubmitUpdate()
{
// Get the user's existing profile data (implementation omitted)
ProfileData profile = GetLoggedInUserProfile();
// Update the user object
profile.EmailAddress = Request.Form["email"];
profile.FavoriteHobby = Request.Form["hobby"];
SaveUserProfile(profile);
ViewData["message"] = "Your profile was updated.";
return View();
}
}
This is all very normal. First, the visitor goes to Edit(), which renders some form to let them change their user profile details. Secondly, they post that form to SubmitUpdate(), which saves the changes to their profile record in the database. There’s no XSS vulnerability here. Everything’s fine, right? We implement this sort of thing all the time…
Unfortunately, this innocent controller is an easy target for CSRF. Imagine that an attacker sets up the following HTML page and hosts it on some server of their own:
<body onload="document.getElementById('fm1').submit()">
<form id="fm1" action="http://yoursite/UserProfile/SubmitUpdate" method="post">
<input name="email" value="hacker@somewhere.evil" />
<input name="hobby" value="Defacing websites" />
</form>
</body>
Next, they somehow persuade a victim to visit this page. When this HTML page loads, it submits a valid form post to /UserProfile/SubmitUpdate on your server.
Assuming you’re using Windows authentication or some kind of cookie-based authentication system such as Forms Authentication, the automated form post will be processed within the victim’s established authentication context, and will successfully update the victim’s email address to something under the attacker’s control. All the attacker has to do now is use your “forgotten password” facility, and they’re taken control of the victim’s account.
Of course, instead of changing an victim’s email address, they can perform any action that the victim can perform with a single POST request. For example, they might be able to grant administrative permissions to another account, or post something defamatory to a CMS.
Ways to stop CSRF
There are two main ways to block CSRF:
- Check that incoming requests have a Referer header referencing your domain. This will stop requests unwittingly submitted from a third-party domain. However, some people disable their browser’s Referer header for privacy reasons, and attackers can sometimes spoof that header if the victim has certain versions of Adobe Flash installed. This is a weak solution.
- Put a user-specific token as a hidden field in legitimate forms, and check that the right value was submitted. If, for example, this token is the user’s password, then a third-party can’t forge a valid form post, because they don’t know each user’s password. However, don’t expose the user’s password this way: Instead, it’s better to use some random value (such as a GUID) which you’ve stored in the visitor’s Session collection or into a Cookie.
Using the AntiForgeryToken helpers
The core ASP.NET MVC package includes a set of helpers that give you a means to detect and block CSRF using the “user-specific tokens” technique.
To use these helpers to protect a particular form, put an Html.AntiForgeryToken() into the form, e.g.,
@using(Html.Form("UserProfile", "SubmitUpdate"))
{
@Html.AntiForgeryToken()
<!-- rest of form goes here -->
}
This will output something like the following:
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
At the same time, Html.AntiForgeryToken() will give the visitor a cookie called __RequestVerificationToken, with the same value as the random hidden value shown above.
Next, to validate an incoming form post, add the [ValidateAntiForgeryToken] filter to your target action method. For example,
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc
}
This is an authorization filter that checks that:
- The incoming request has a cookie called __RequestVerificationToken
- The incoming request has a Request.Form entry called __RequestVerificationToken
- These cookie and Request.Form values match
Assuming all is well, the request goes through as normal. But if not, boom!, there’s an authorization failure with message “A required anti-forgery token was not supplied or was invalid”.
This prevents CSRF because even if a potential victim has an __RequestVerificationToken cookie, an attacker can’t find out its value, so they can’t forge a valid form post with the same value in Request.Form. But legitimate users aren’t inconvenienced at all; the mechanism is totally silent
Anti-CSRF and AJAX
The simple solution for adding AJAX Cross-Site request forgery is to add the Request Verification Token to the data
function CallAjax() {
var data = { "ajaxparameter ": 'hello moon' };
data.__RequestVerificationToken = $("input[name=__RequestVerificationToken]").val();
$.ajax({
type: "POST",
url: '@Url.Action("AjaxCall")',
dataType: "json",
data: JSON.stringify(data),
success: function () {
alert('Ajax call succesful');
}
});
return false;
}
this can also be done via the $ajaxSetup
$.ajaxSetup({
global: true,
beforeSend: function (xhr, settings) {
if (settings.data != "") {
settings.data += '&';
}
settings.data += '__RequestVerificationToken=' + $("input[name=__RequestVerificationToken]").val();
}
});
this then leaves the AJAX call as you would normally find it
function CallAjax() {
var data = { "ajaxparameter ": 'hello moon' };
$.ajax({
type: "POST",
url: '@Url.Action("AjaxCall")',
dataType: "json",
data: JSON.stringify(data),
success: function () {
alert('Ajax call succesful');
}
});
return false;
}
The form token can be a problem for AJAX requests, because an AJAX request might send JSON data, not HTML form data. One solution is to send the tokens in a custom HTTP header. The following code uses Razor syntax to generate the tokens, and then adds the tokens to an AJAX request. The tokens are generated at the server by calling AntiForgery.GetTokens.
<script>
@functions{
public string TokenHeaderValue()
{
string cookieToken, formToken;
AntiForgery.GetTokens(null, out cookieToken, out formToken);
return cookieToken + ":" + formToken;
}
}
$.ajax("api/values", {
type: "post",
contentType: "application/json",
data: { }, // JSON data goes here
dataType: "json",
headers: {
'RequestVerificationToken': '@TokenHeaderValue()'
}
});
</script>
When you process the request, extract the tokens from the request header. Then call the AntiForgery.Validate method to validate the tokens. The Validate method throws an exception if the tokens are not valid.
void ValidateRequestHeader(HttpRequestMessage request)
{
string cookieToken = "";
string formToken = "";
IEnumerable<string> tokenHeaders;
if (request.Headers.TryGetValues("RequestVerificationToken", out tokenHeaders))
{
string[] tokens = tokenHeaders.First().Split(':');
if (tokens.Length == 2)
{
cookieToken = tokens[0].Trim();
formToken = tokens[1].Trim();
}
}
AntiForgery.Validate(cookieToken, formToken);
}
Using salt
Salt? What? In case you want to protect multiple forms in your application independently of each other, you can use a “salt” value when you call Html.AntiForgeryToken(), e.g.,
@Html.AntiForgeryToken("someArbitraryString")
… and also in [ValidateAntiForgeryToken], e.g.,
[ValidateAntiForgeryToken(Salt="someArbitraryString")]
public ViewResult SubmitUpdate()
{
// ... etc
}
Salt is just an arbitrary string. A different salt value means a different anti-forgery token will be generated. This means that even if an attacker manages to get hold of a valid token somehow, they can’t reuse it in other parts of the application where a different salt value is required
Load balancing
Will different web servers in a load balanced configuration create the same token in the HTML forms?
If all machines across the farm share the same <machineKey>, everything will work. There are lots of resources on how to set this. There’s also a tutorial on MSDN.
Note that the name <machineKey> is a bit misleading, since this is actually set per-application in ~/Web.config. So set the <machineKey> explicitly in your app’s Web.config, then deploy across your farm.
Limitations of the Anti-Forgery helpers
ASP.NET MVC’s anti-CSRF helpers work very nicely, but you should be aware of a few limitations:
- All legitimate visitors must accept cookies (otherwise, [ValidateAntiForgeryToken] will deny their form posts). Arguably this isn’t a limitation, because unless visitors allow cookies, you probably don’t have anything to protect anyway.
- It only works with POST requests, not GET requests. Arguably this isn’t a limitation, because under the normal HTTP conventions, you shouldn’t be using GET requests for anything other than read-only operations.
- It’s easily bypassed if you have any XSS holes on your domain. An XSS hole would allow an attacker to read a victim’s anti-forgery token value, then use it to forge valid posts. So, don’t have XSS holes!
- It relies on the potential victim’s browser implementing cross-domain boundaries solidly. Browsers are supposed to stop foreign domains from reading your app’s response text and cookies, and are supposed to stop foreign domains from writing cookies to your domain. If an attacker manages to find a way around this, they can bypass [ValidateAntiForgeryToken]. Of course that’s not supposed to be possible. For the most part, modern browsers block this line of attack.
Links
The Open Web Application Security Project
The orginal article was produced by Steven Sanderson:
Prevent Cross-Site Request Forgery (CSRF) using ASP.NET MVC’s AntiForgeryToken() helper
Source for this article
CrossSiteRequestForgery.zip (3.21 mb)