XSRF token not needed for Ajax requests about tornado HOT 13 CLOSED

Here's a patch:

diff --git a/tornado/web.py b/tornado/web.py
index 08047a4..bc626a8 100644
--- a/tornado/web.py
+++ b/tornado/web.py
@@ -590,6 +590,9 @@ class RequestHandler(object):

         See http://en.wikipedia.org/wiki/Cross-site_request_forgery
         """
+        if self.request.headers.get("X-Requested-With") == "XMLHttpRequest":
+            return
+        
         token = self.get_argument("_xsrf", None)
         if not token:
             raise HTTPError(403, "'_xsrf' argument missing from POST")

from tornado.

Wouldn't you be able to forge the http header X-Requested-With if you are an attacker and bypass this protection mechanism?

from tornado.

As I understand, no, since modification of request headers needs to be done programmatically using javascript, flash, java, etc. These environments implement the "same origin policy" so that requests may only be sent to the same domain that the scripts are served from.

Here's some more info if you're interested:
http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy

from tornado.

Fixed: http://github.com/facebook/tornado/commit/c50d9b8c789eb1914f31bd4dc7adbf1383c8fdb1

from tornado.

Forgive me for digging up an old issue, but I agree with araddon. Web browsers aren't the only method of sending an HTTP request; it's only the script/flash/etc within the browser that can't spoof it. Disabling a security function based solely on the existence of a spoofable header seems very bizarre to me. (EDIT: You might even be able to use curl to spoof it, I don't know. I've never used curl. But that would be a very easy way to bypass the XSRF protection.)

from tornado.

The fix for this was committed long ago, Twisol

from tornado.

Right; I'm suggesting rolling it back. Should I open a new issue? I've never done this before.

from tornado.

Twisol, XSRF attacks must originate from the user's browser.

The attack works like this:
Say you visit Site A and log in -- your browser now has a cookie which identifies you on each request. The attack happens if you visit Site B, and unknowingly submit a form which POSTs to Site A using your credentials.

Tornado protects against this is by using a randomly generated XSRF token. This token is set as a cookie and also sent in each POST request. If the user's cookie matches the token sent in the request, then the request is valid. This is because Site B cannot access cookies from Site A and therefore cannot send the correct XSRF token to validate the request.

AJAX requests however, are special in that they are restricted to the same domain. Therefore, a POST cannot be made from Site B to Site A using the visitor's credentials.

Hope I explained it well. If you want more info, I'd check out Wikipedia:
http://en.wikipedia.org/wiki/Cross-site_request_forgery

from tornado.

Hmm, okay... If I may suggest my own scenario:

The user visits a site and has the XSRF token and user ID placed in cookies. Third-party code somehow gets into the page, perhaps through content submitted by another user, and gets the user's ID cookie. If I understand it right, the XSRF token will be invalidated after a certain period of time, right? But once the attack has the user's ID, they can spoof an AJAX request by using, say, cURL and adding an X-Requested-With header. That bypasses the XSRF token check, and they have the user's ID cookie, so they get through security.

Thanks for taking the time to listen, by the way. I understand that this is an old issue, and it's probably annoying to deal with some impertinent whippersnapper who doesn't know what he's talking about. But thanks for putting up with it.

from tornado.

No problem, it's good to question things, that's how bugs are found =)

The scenario you described could happen, and has happened before. However, it's not what the token is meant to protect from. This is a different attack, called XSS (or cross-site scripting) in which a user can insert a script into your site's page.

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

The way to protect against this is to always escape or validate user generated content.

from tornado.

Alright, fair enough. Does leaving the XSRF check in cause so many problems that it's not worth the extra security, though? It's easy to forget, sometimes, to check user content, but it's not hard to always check the XSRF token, especially since it's built into Tornado. XSS wouldn't be totally blocked by keeping the XSRF check, but I would imagine it's still helpful to have. (EDIT: Strictly speaking, it only blocks one of the possible uses of XSS, but one which I think is related to XSRF)

This patch was only two lines, after all.

from tornado.

It doesn't really make sense, though. If there is an XSS bug, you can just read all the cookies out and use them, so there is no need for XSRF; you can just send the cookies to some malicious server and then use them directly. If you have an XSS bug, XSRF is not necessary to compromise any account.

It is a big deal to leave in because it means every user of Tornado has to instrument their JavaScript libraries to include the XSRF argument, which led to a lot of developer confusion and issues.

from tornado.

Adding the _xsrf parameter to my AJAX requests was very simple, for me. Honestly, I'm having more trouble with getting the blasted thing (kidding) to set the XSRF cookie in the first place. But that's unrelated...

On your first paragraph, I'm not sure I follow. Once you've stolen the cookies and copied them elsewhere, how else would you use them but to send them through a manufactured page or crafted HTTP request? Leaving out the X-Requested-By check would at least prevent the attack from that angle[1]; I think they would have to send an AJAX request straight from the infected page to do anything. But at least it happens in front of the user, and not at someone else's computer.

[1] Well, that's also assuming the attack takes place within the timeframe that the XSRF token stays valid. But that's still a smaller window of time...

EDIT: At any rate, you've made it clear that my suggested scenario would open many more holes than just this, so I suppose this is probably the least of one's worries. I guess it's not such a big deal. Thanks for setting me straight!

from tornado.