20061224

I Take it Back!

After some personal practice on XSRF, it's just WAY too easy. I'm not entirely certain there's a GOOD way for browsers to work around it (again, developers should protect their own apps and not rely on the browsers to do it for them).

My most recent toying with it, I was able to use an iframe to do the work, and had to do a little trickery to work around the fact that the victim site actually required a "submit" attribute, so the iframe couldn't call the "submit" method on the form. I tried to do some stuff like not setting the attribute initially, then using DOM to get a reference to the submit function (which is an object), then set the attribute, then do a .call on the object, but to no avail. Eventually had to cheat and make a proper submit button and call .click - blech. But it's hidden from sight, and if there are enough images on the attacker site, requests to the victim site will just be a blur in the status bar among all the requests to the attacker site.

Now, I wouldn't give all this bad news if I didn't have a remediation.

These raise the bar, but DO NOT remove the problem:
- Use POST instead of GET
- Shorten the session timeout
- Use an absolute session length - (one of only a few things .NET got right)
- Check the referrer

The only real solutions are to do things like:
- If the request is one that must come from XmlHttpRequest, then do request fingerprinting - set a unique header in the request.
- Use a transaction token - such as the Struts Action.isTokenValid() Action.saveToken(). It's not hard to cobble this together by hand if you're not using Struts. And I think .NET does some stuff with the userstate to ensure that you came from the right place.
- Use a CAPTCHA or TID - something that requires human interaction. (This is just like the transaction token above, except the user enters a value, rather than it being included on a hidden element.)

So after the holidays, you developers need to get back to work and start authenticating individual transactions. '07 is going to be a LOVELY year for XSRF.

0 comments: