Understanding Cross-Site Request Forgery in .NET

If you run the site again and go to the /Home/AttackForm page, you’ll see that it loads up just fine, but with no outward indication that anything has happened. If you now go to the /Account/ChangeEmail page though, you’ll see that your email has been changed to [email protected]. Here of course, we’re intentionally making this obvious, but in a real attack, you might not notice that your email has been modified.

Mitigating Cross-Site Request Forgery

There are two primary ways to mitigate this type of attack. First, we can check the referral that the web request arrives from. This should tell the application when a form submission does not come from our server. This has two problems though. Many proxy servers remove this referral information, either intentionally to protect privacy or as a side effect, meaning a legitimate request could not contain this information. It’s also possible for an attacker to fake the referral, though it does increase the complexity of the attack.

The most effective method is to require that a user specific token exists for each form submission. This token’s value should be randomly generated each time the form is created and the form is only accepted if the token is included. If the token is missing or a different value is included, then we do not allow the form submission. This value can be stored either in the user’s session state or in a cookie to allow us to verify the value when the form is submitted.

ASP.NET makes this process easy, as CSRF support is built in. To use it, we only need to make two changes to our website.

Fixing the Problem

First, we must add the unique token to the form to change the user’s email when we display it. Update the form in the ChangeEmail.aspx view under /Account/ChangeForm:

<% using(Html.BeginForm()) { %>    <%: Html.AntiForgeryToken() %>    <%: Html.TextBoxFor(t=>t.NewEmail) %>    <input type="submit" value="Change Email" /><% } %>

This new line: <%: Html.AntiForgeryToken() %> tells ASP.NET to generate a token and place it as a hidden field in the form. In addition, the framework handles placing it in another location where the application can access it later to verify it.

If we load up the page now and look at the source, we’ll see this new line, in the form, rendered to the browser. This is our token:

<form action="/Account/ChangeEmail" method="post"><input name="__RequestVerificationToken" type="hidden" value="g_ya1gqEbgEa4LDDVo_GWdGB8ko0Y91p98GTdKVKUocEBy-xAoH_Pok4iMXMxzZWX_IDDAXEkVwu3gc6UNzRKt8tjZ88I9t4NE8WT0UTT0o1" />    <input id="NewEmail" name="NewEmail" type="text" value="" />    <input type="submit" value="Change Email" /></form>

We also need to make a change to our action to let it know that we’ve added this token and that it should verify the token before accepting the posted form.

Again this is simple in ASP.NET MVC. At the top of the action that we created to handle the posted form, the one with the [HttpPost] attribute added, we’ll add another attribute named [ValidateAntiForgeryToken]. This makes the start of our action now look like the following:

    [HttpPost]    [ValidateAntiForgeryToken]    public ActionResult ChangeEmail(ChangeEmailModel model)    {        string username = WebSecurity.CurrentUserName;        *rest of function omitted*

Let’s test this out. First go to the /Account/ChangeEmail page and restore the email for your account to a known value. Then we can return to the /Home/AttackForm page and again the attack code attempts to change our email. If you return to the /Account/ChangeEmail page again, this time you’ll see that your previously entered email is still safe and intact. The changes we made to our form and action have protected this page from the attack.

If you were to look at the attack form directly (easily done by removing the <iframe> tags around the form on the attack page, you’ll see the error that actually happens when the attack form attempts to post.

These two additional lines added to the site were enough to protect us from this error.

---

Conclusion

Cross-site request forgery is one of the most common and dangerous attacks on websites. They are often combined with other techniques which search out weaknesses in the site to make it easier to bring about the attack. Here I’ve demonstrated a way to secure your .NET site against this type of attack and make your website safer for your users.