Question

From my research, the proper way to protect against this is to set a NONCE with every GET request that returns a form and then check for the NONCE on the POST request. However, someone could still write a script to GET my form along with the NONCE and then POST it back with the NONCE.

Since this is such a widely known vulnerability, shouldn't browsers already take care of that by not allowing cross-domain ajax calls? If not, does ASP.NET MVC 4 already have a built-in mechanism to protect against this?

Was it helpful?

Solution 2

Yes there is a built in mechanism. HtmlHelper.AntiForgeryToken, which can be used to help protect your application against cross-site request forgery. To use this feature, call the AntiForgeryToken method from a form and add the ValidateAntiForgeryTokenAttribute attribute to the action method that you want to protect.

CSHTML file:

@Html.AntiForgeryToken()

Controller:

[ValidateAntiForgeryToken]
public ActionResult Edit(User updatedUser)

You'll note that the token involves two safety measures -- a form field and a cookie:

To generate the anti-XSRF tokens, call the @Html.AntiForgeryToken() method from an MVC view or @AntiForgery.GetHtml() from a Razor page. The runtime will then perform the following steps:

  1. If the current HTTP request already contains an anti-XSRF session token (the anti-XSRF cookie __RequestVerificationToken), the security token is extracted from it. If the HTTP request does not contain an anti-XSRF session token or if extraction of the security token fails, a new random anti-XSRF token will be generated.

  2. An anti-XSRF field token is generated using the security token from step (1) above and the identity of the current logged-in user.

  3. If a new anti-XSRF token was generated in step (1), a new session token will be created to contain it and will be added to the outbound HTTP cookies collection. The field token from step (2) will be wrapped in an element, and this HTML markup will be the return value of Html.AntiForgeryToken() or AntiForgery.GetHtml().

Reading:

XSRF/CSRF Prevention

Wikipedia CSRF

OTHER TIPS

Those nonces are used for protecting against cross site request forgeries. A cross domain ajax call is not necessary to make that happen - and browsers do have protections against those. CSRF is a vulnerability because when a browser makes a call to your site, it sends the session information for your site, regardless of the page that told the browser to make the call. The browser can be told to make a get request to your site.com by including an img tag on evilsite.com that points to a page on your site.com. If when that get request is processed by yoursite.com you validate the nonce, there is no way that a drive by of evilsite.com would know the nonce. Similar things can be done for post requests as well.

This page seems to have some information about how to mitigate this in ASP.NEt MVC: http://www.asp.net/mvc/overview/security/xsrfcsrf-prevention-in-aspnet-mvc-and-web-pages

Cheers, Stefan

You should also take a look at the concept of stateless CSRF protection. There are 2 standard approaches to achieving this: the Encrypted Token Pattern and the Double Submit Cookie pattern. The Encrypted Token Pattern leverages a Rijndael-encrypted Token which contains a built-in nonce value that can’t be read by scripts, and is a very strong cryptographic structure.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top