4 ms·

Good explanation, thanks. The part I don't understand is the POST hitting the victim app. I don't know django but rails apps require an authenticity token to b

• euroclydon 16y ago
  Rails WAS configured to accept the token OR a custom header, relying on the fact that custom headers can't be created cross domain. The patch fixes this, by requiring BOTH. Hmmm... So how do they know what the custom header is? Are they typically static?
  • cheald 16y ago
    The CSRF token is generated and stored in the user session, so rather than just X-Requested-With: XMLHttpRequest, you now also get an X-CSRF-Token: <some token stored in the user session>. Rails doesn't check for XRW anymore; it just cares that you passed a valid CSRF token through, either as a POST variable (normal POST/PUT/DELETE) or in the X-CSRF-Token header (AJAX). In case you're wondering, yes, this does make caching with Varnish a bitch and a half.
    • euroclydon 16y ago
      I want know how the exploit works. The Flash app has to write a custom header. How does it know the value to put in the header, unless it's always the same for all sessions across all users. P.S. You cache POST/PUT/DELETES?
      • nbpoole 16y ago
        That's the point of the fix: X-CSRF-Token requires the CSRF token, which is per-user, as its value. X-Requested-With, the old way of doing things, just had to be present in the request.
      • SoftwareMaven 16y ago
        The exploit SWF just puts in that it is an Ajax call: X-Requested-With: XMLHttpRequest which says "I'm an AJAX request". Since the value is static, it is easy to use in an exploit.
      • jbri 16y ago
        If you cache the page from which a user submits a POST/PUT/DELETE, how are they going to get their CSRF token?
      • cheald 16y ago
        That's the point of the fix. The header is custom per user now. Before, the presence of the "X-Requested-With: XmlHttpRequest" header was enough to let Rails assume the request was legit. Since Flash doesn't respect the victim's crossdomain.xml, this is no longer a valid assumption, and you have to use a unique header per session. This means writing this unique value out into the page somewhere, to be included with any AJAX requests, which means that you cannot cache these pages as you might before, since AJAX calls would fail for everyone except the person who populated the cache.
• rst 16y ago
  The bug was that Rails didn't check for the authenticity token in case of requests that were labeled as XmlHttpRequest (i.e., Ajax), and the redirect-from-flash game allows the attacker to forge the label. The fix makes it check in all cases; this is why it comes with stuff that you're supposed to patch into your layouts and application.js to put authenticity tokens into all your Ajax calls.