Menu
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?
569
Anti-Forgery Tokens The server includes two tokens in the response. One token is sent as a cookie. The other is placed in a hidden form field. The tokens are generated randomly so that an adversary cannot guess the values.
To consume Web API in ASP.NET MVC server side we can use HttpClient in the MVC controller. HttpClient sends a request to the Web API and receives a response. We then need to convert response data that came from Web API to a model and then render it into a view.
Step 1: Open Visual Studio and click on New Project. Step 2: Select the ASP.NET Web Application and enter the name for the application. Step 3: Select Web API Project Template and tick the check box of MVC and click OK. Visual Studio automatically creates the Web API application using the MVC 5 based projects.
You may use HttpClient in other . NET applications also such as MVC Web Application, windows form application, windows service application etc. Let's see how to consume Web API using HttpClient in the console application. We will consume the following Web API created in the previous section.
Require antiforgery validation ValidateAntiForgeryToken is an action filter that can be applied to an individual action, a controller, or globally. Requests made to actions that have this filter applied are blocked unless the request includes a valid antiforgery token.
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?
When would you want to use an AntiValidationToken for an API Controller? The anti-forgery token is designed for browser based HTML forms to prevent cross site scripting vulnerabilities. Web API uses CORS to grant/deny browser based AJAX calls from a domain other than the domain that rendered the page.
"The ValidateAjaxAntiForgeryToken only works when the user is authenticated and it will not work for anonymous requests." @Rudey - hmmm. are you sure about this?
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.
99
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
