XSRF protection in an AJAX style app

Question

We're currently developing an entirely AJAX based app that will interact with the server via a RESTful API. I've considered potential schemes to protect against XSRF attacks against the API.

1. User authenticates and receives a session cookie, which is also double-submitted with each request.

2. We implement an OAuth consumer in Javascript, retrieve a token when the user logs in, and sign all requests with that token.

I'm leaning toward the OAuth approach, mainly because I'd like to provide 3rd party access to our API and I'd rather not have to implement two authentication schemes.

Is there any reason why an OAuth consumer would not work in this situation?

Answer 1

The easiest way to prevent XSRF it to check the referer of every RESTful request to make sure the request is coming from the same domain. The session cookie is important for keeping state, but it will not defend against XSRF becuase it will also be sent with a forged request. Its common to see referer based XSRF protection system on embedded network hardware with limited memory requirements, Motorola uses this method on most of their hardware. This isn't the most secure XSRF protection, token based protection is better but both systems can still be bypassed with XSS. The biggest problem with token based XSRF protection is that it takes alot of time to go back and fix every request and you will probably miss a few requests.

Make sure to read up on the same origin policy and to scan your site for xss. You should also read the OWASP Top 10 for 2010 A3-Broken Authentication and Session Management.

Answer 2

Most AJAX libraries will set an additional header "X-Requested-With: XMLHttpRequest", which is difficult to fake in a basic XSRF attack (though possible if combined with XSS). Verifying that this header exists is a good defense-in-depth strategy if you expect all your requests to be AJAX.

Answer 3

Use a two-step request, the first asking for the server an unpredictible token, the second asking for the real action with the token.

As the attacker can't predict the token, and can't read it (same origin policy) he can't give a valid token in the second query.

But be careful to not leak tokens (learn about capturing json using when they affect value to a global variable and so on) and read :

http://www.google.com/search?q=xsrf+defence