22

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?
Dan2552
  • 323
  • 1
  • 2
  • 4
  • 1
    See http://stackoverflow.com/questions/5207160/what-is-a-csrf-token-what-is-its-importance-and-how-does-it-work – Quandary Sep 15 '16 at 06:27

1 Answers1

23

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

Vitaly Osipov
  • 863
  • 6
  • 14
  • 1
    Thanks for your response. Regarding Q1 (I apologise of my lack of knowledge of web client-side capabilities, I know pretty much nil), if a malicious Flash content can send off a POST request, surely it has the capability of a response handler? If not, fair enough; but if it does, what's there to stop it grabbing the token there? – Dan2552 Dec 23 '12 at 01:38
  • 2
    @Dan2552: It can't. That's what the Same-Origin Policy is. – SLaks Dec 24 '12 at 21:01
  • @Dan2552 The malicious Flash plugin from site B cannot read cookies (or anything really, IIRC) from the site A. Same-origin policy prevents that, as have already been noted. It's good to have a questioning mind, but remember that topics like this have been researched to death over the past 10+ years ;) – Vitaly Osipov Dec 21 '18 at 01:54