How does a CSRF token prevent an attack, and how can I safely use/avoid it for my JSON API?

Question

I'm trying to make an iOS app communicate with a Ruby on Rails website using JSON. While trying to post a login to create a user session, I discovered I was missing a CSRF token. I had no idea what that is at all, so I started looking into it, and found some solutions that say to remove the CSRF protection if the call format is 'application/json'. But that sounds like that leaves the website vulnerable?

Some results came up about JS forms having the same issue. The answers there were to add in the CSRF token. Which upon inspection, also appears to be in meta content tag in page headers.

So this leaves me in confusion, here's my questions:

• How does the token help protect anything if it can be read in prior call to the attacking call? Can a malicious site not simply make a request, parse the received message, and send another request with the token?
• Would it be safe to disable the token-check on the login post action, and have it send back the token along with the success response? If not, any better suggestions?

Answer 1

A summary of how CSRF attacks work goes like this:

1. You, the good user, while logged into a web site A, visit some other site's page B.
2. That page does a GET (can be a POST, a little more complex to set up) to a page X on site A (which you are logged in to), with e.g. . Your browser obliges, using your already authenticated session/cookie
3. Page X by design causes change in state of your account - classic examples are "transfer X dollars to B" (less realistic) or "set user status line to PWNED" (more realistic)

There are a number of ways a CSRF token can be implemented, but the idea is that a simple GET request to a state-changing URL X will not work unless an additional changing piece of information (the token) is included, e.g. it has to be "X?token=123123213". Since the token changes reasonably often, the step 2 above will not work. The would-be attacker does not know the current token.

Your question 1 - the attacker does not see the content of the page X, he only forces you to visit it.

Your question 2 - since this is all about actions when already logged in, it is more or less ok to not use CSRF protection on the login page. There is a chance that you can be forced to log in as someone else and not notice it, though.

http://en.wikipedia.org/wiki/Cross-site_request_forgery

A more general class of issues is http://en.wikipedia.org/wiki/Confused_deputy_problem