I've read several XSRF solutions that rely on adding more tokens to the response, which do help protect code that only runs on POST.
i.e. this would be a one step attack relying on a page that responds to HTTP GET
<img src="http://amazon.com/buybook/anarchistscookbook/mailto/me/execute.php">
But with better libraries like jquery, its getting easier to write malicious javascript XmlHttpRequest scripts, that can do a two step attack (a GET, parse the Anti-XSRF viewstate/query string/extra cookie etc) and then submit a POST. (Or is it? I don't worry about AES being cracked any time soon, should I even worry about 2 step XSRF attacks targeting HTTP POST actions becoming as easy as the img tag attack shown above?)
I suppose the one step attack can mostly be tharted by not doing anything sensive on GET, could both kinds of attacks be tharted by requiring the website user to solve a CAPTCHA, which then yeilds a query string token that would be required for all URLs for the rest of the session?
So far it seems like it would only fail when CAPTCHA fails, such as if OCR software can read the text or if there is a mechanical turk component.
EDIT: The particular attack in mind is an email with xhr javascript or image tag. So the code would be executing in email client's browser or from a HTML page loaded from the local filesystem. For simplicities sake, I'm imagining the site has no XSS vulnerabilties (ie. no opportunities for malicious users to inject their HTML into the HTML the site sends as responses)
The point is that JavaScript can't read the anti-XSRF token from a cross-domain context, and XMLHTTPRequest is same-origin only, so it cannot be used to steal the token.
If your site already has a XSS vulnerability, you're already hosed, and anti-XSRF tokens won't help you.