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?

Texas

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.

Neodymium

as far as I'm aware "X-Requested-With" headers are not put in the request nativly, only by frameworks like jquery – Oldster

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.

Haily

I already have an anti-CSRF implementation (via the DotNetNuke Services Framework), I'm just trying to understand how/if it works with native apps. I don't see anything in the SPA template that would enable their APIs to work if there's no AJAX or form POST. – Texas

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.

Jokester

Restricting to localhost doesn't seem to help with a native mobile application, right? – Texas

Well I was using phonegap, which was running locally on the client. – Jokester