How does ValidateAntiForgeryToken fit with Web APIs that can be accessed via web or native app?

Question

I'm trying to understand how I will be able to craft an API using ASP.NET Web API which will be protected from CSRF, while still being accessible from non-web environments (e.g. native mobile applications).

My first thought would be that a non-web environment can never successfully pass an anti-forgery token validation, since it doesn't have a form that is posted. Is this true? Is there any way to make validation work?

If there isn't a way to validate, my second thought is to offer an API which validates anti-forgery tokens for web calls but not for non-web calls. However, it seems like an attacker would just as easily be able to use this "non-web" API for a CRSF attack, right?

Is the answer that the non-web API needs to only support a non-web authentication mechanism (OAuth?), so that requests to it cannot be replayed via a browser? Or is there a simpler way?

If that's the only way, is there an easy way to turn off all of the insecure authentication mechanisms? Shouldn't there be a somewhat simple/happy path in ASP.NET Web API to support these scenarios?

Answer 1

CSRF only becomes a problem when you are using a persistent auth mechanism such as cookies, basic auth, NTLM etc. Mike Wasson has an example of using CSRF against webapi in Javascript - and I've seen versions in DelegatingHandlers ....

As CSRF is only a problem in web scenarios you can argue there's no real need to check for non-web requests. Every ajax request from a browser, whether via jquery, the native XmlHttpRequest classes or whatever comes with a header - X-Requested-With, which will have a value of XMLHttpRequest. So you could limit your CSRF checks to just requests with that header, as anything without it must have come from outside a browser.

Having said that if you are authenticating, I'd look at some sort of shared secret or OAuth mechanism, and have a DelegatingHandler server side to validate, and in the web app just put the token somewhere that it can be picked up via javascript and sent via an X-Authentication header - as it's not persistent and needs to be attached to every request (just like the CSRF token) there's no CSRF problems. Dominick, as ever, documents this sort of thing well.

Answer 2

Have a look at the SPA templates in the latest MVC4 update. They have a sample implementation for Anti-CSRF for Web API.

Answer 3

Take a look at the CORS implementation for WebAPI.

http://blogs.msdn.com/b/carlosfigueira/archive/2012/07/02/cors-support-in-asp-net-web-api-rc-version.aspx

Then you could allow only localhost as a valid URI on the webapi server. This would prevent other sites from loading attack code in the browser.