More thoughts on XSRF

Okay, so I said at one point "there's nothing new with XSRF." That's true. And I'm not sure if it's a sleeping giant. However, it's not something to not be concerned about.

I haven't looked at the parameters that go across or anything, but I could see this working very well against sites like <insert major bookseller with one-click here>. The big deal with <insert major bookseller with one-click here> is that you store your credit card info on the site so you don't have to continually re-enter it. If it also has a stay-logged in feature, you could make a malicious site (or a blog) with a workflow something like this:

- User views static image, which changes the user's address on file
- Javascript with a setTimeout() to create a new Image JS object, whose source is to add an item to the cart.
- Javascript with a setTimeout() to run after the previous, with checkout instructions. All of this without using an XmlHttpRequest - since that won't go cross domain.

And yes, doing a DOM call to make the new image tag and load its source from off-domain works.

So why is this so awful? And what can you do to truly protect against it?

It's so awful, because in your own assessments, it doesn't even really require a "stay logged in" feature. If the session timeout is too long, and you can either: 1) do persisted HTML injection, or 2) trick the user into visiting your site while they're still logged in, then your site may still be vulnerable to it. Fortunately, there are lots of ways to protect against it, like:
- Token passing (put a nonce in the user's session, check the nonce when they submit the form)
- Require POST, not GET
- CAPTCHA
- Force sensitive operations to require the user's password

The most elegant of these are the first two because they work without user interaction. If a bad guy is able to request the form (in the token passing example), they won't be able to get the token out of what got sent back to the user - not without using XmlHttpRequest, which can't go cross-domain. And the second pretty much cures all of it unless you can somehow get it to work with XmlHttpRequest.

But you REALLY need to catch these things during the design phase. Shoehorning in CAPTCHA or token passing after the fact is very difficult. If you add it early, it's much easier to deal with, and the developers begin to adopt the fix as a matter of practice, not as a response to a discovered vulnerability.