Do I need a CSRF token for jQuery .ajax()?
The risk from CSRF is that an external site could send data to yours and the users browser will automatically send the authentication cookie along with it.
What you need is some way for the receiving action (that your $.ajax() method is sending POST data to) to be able to check that the request has come from another page on your site, rather than an external site.
There are a couple of ways to do this, but the recommended way is to add a token to the request that you can check for and that the hackers can't get to.
At its simplest:
- On log on create a long random string token and save it against the user.
- Add a parameter to the
$.ajax()request that includes the token. - On request check that the token matches the one that you have saved for the user.
- If the token doesn't match you have a CSRF hack.
The hacker can't get to your DB and can't actually read the page you've sent to the user (unless they get an XSS attack in, but that's another problem) so can't spoof the token.
All that matters with the token is that you can predict (and validate) it and that the hacker can't.
For this reason it's easiest to generate something long and random and store it in the DB, but you could build up something encrypted instead. I wouldn't just MD5 the username though - if the CSRF attackers figure out how to generate your tokens you'll be hacked.
Another way is to store the token is in a cookie (rather than your database), as the attackers can't read or change your cookies, just cause them to be re-sent. Then you're the token in the HTTP POST data matches token in the cookie.
You can make these a lot more sophisticated, for instance a token that changes every time it's successfully used (preventing resubmission) or a token specific to the user and action, but that's the basic pattern.
In terms of request forgery, it doesn't matter how the client sends the request it matters how its received. The same CSRF rules apply for an ajax post as any other type of post.
I recommend reading the CSRF prevention cheat sheet. Using a per-user secret token is the most common form of protection.
Strictly, no token is needed, but you should still protect any functions that change state against CSRF.
CRSF is most definitely a risk, even though the request is made via AJAX. This is because AJAX requests can be passed cross-domain - the Same Origin Policy only guards against reads, not writes. And also a traditional form might be able to send exactly the same POST request as your AJAX does, and your current server-side code might not detect this.
One simple way of allowing your server-side code to detect whether the request has come from your own site is by adding a header that is sent with the AJAX request. It is important that your server-side code checks for the presence of this header. No random token is necessarily needed.
This works because:
- HTML forms cannot have custom headers added to them by an attacker.
- Custom headers cannot be passed cross-domain without CORS being enabled.
For a defence against any future developments on the web, it might be a good idea to also implement a random token. This would need to be tied to the current user session in some way. It isn't currently exploitable if the token isn't implemented, but in the web's long and twisted history, lack of tokens could be exploited by Flash and other browser plugins. In a perfect world, HTML5 and the living standard should mean that plugins like these are a thing of the past, however, who knows for sure what is around the corner so to add defence-in-depth and to future proof, tokens are also recommended.