These guys are not the only ones to make this mistake. Check the first line of Tornado's XSRF check:<p><pre><code> def check_xsrf_cookie(self):
"""Verifies that the '_xsrf' cookie matches the '_xsrf' argument.
To prevent cross-site request forgery, we set an '_xsrf' cookie
and include the same '_xsrf' value as an argument with all POST
requests. If the two do not match, we reject the form submission
as a potential forgery.
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")
if self.xsrf_token != token:
raise HTTPError(403, "XSRF cookie does not match POST argument")</code></pre>
Since this also affected Rails, a minor clarification:<p>We spoke with Ben Bangert of Pylons/Pyramid, and did some checking of source code there and in other projects, and as far as we knew last week, Django was the only Python framework affected by the CSRF issue. If you find another project which is affected, please notify them ASAP.
Cross-posting the recent discussion about the new Ruby on Rails release, which included a fix for the same CSRF issue:<p><a href="http://news.ycombinator.com/item?id=2195283" rel="nofollow">http://news.ycombinator.com/item?id=2195283</a>
A bothersome change, especially for all those employing jQuery plugins that don't have a quick method to add the CSRF token to AJAX requests.<p>I think I might just add @csrf_exempt, as long as we aren't changing vital info via the request...
"This is technically backwards-incompatible, but the security risks have been judged to outweigh the compatibility concerns in this case."<p>Good choice. I wonder when weak password hashing in Django will be given the same exception.