Here's what happens in a typical Rails app:
Recently hackers have attacked via AJAX, so Rails recently added similar protection for AJAX.
In parallel, jQuery recently added the new ajaxPrefilter chain, which makes it possible for developers to add Rails security for AJAX connections.
A secure token in this context is a long string of random characters. The string must be web safe because the string may appear within a web page, or a URI.
The token is typically put on the page in one or more ways.
<meta name="csrf" content="abcdefjklmnopqrstuvwxyz="/>
<input type="hidden" name="csrf" value="abcdefjklmnopqrstuvwxyz">
To look up the token using jQuery, we use code like this:
csrf = $('meta[name=csrf]').attr('content'),
To add the token to an AJAX request on the fly, we use jQuery ajaxPrefilter:
The jQuery ajaxPrefilter is new in jQuery 1.5. Some older blog posts describe ways to accomplish much the same goal by using jQuery beforeSend, or jQuery ajaxSend.
Rails provides much of the infrastructure for tokens, so if you're interested in learning more here are key tems:
The Rails built-in commands do tokens for HTTP POST requests, but not for HTTP GET requests. This is because the Rails developers say that HTTP GET requests do not change data, so are safer; i.e. if a hacker does session hijacking, then he would be able to see data, but not change data.
Our opinion is that HTTP GET should also be protected.
Rails provides the token dynamically. When we use markup languages like Mustache, Handlebars, and Liquid Markup, we provide the token to the markup engine.
One way to make the token string web-safe is to use Base64 encoding. This is how Rails does it.
However, Base64 can sometimes use characters like the plus sign "+" which are interpreted differently within URIs: a plus sign get translated to a space, which is not what Base64 wants.
In our experience, it's more reliable and more universal to use strings that contain only letters and numbers, and no symbols.