You can read the advisory here(pdf)
I disagree a little bit with their pinning of the problem on the AJAX libraries. Ultimately, their example relies upon a server giving up data w/o any kind of check other than the session check. That kind of vulnerability isn’t restricted to AJAX libraries.
The idea of wrapping the response with special characters is easily worked around. I’ve poked fun at envelopes like SOAP and XML-RPC before because even if you get a malformed request, you can still get at the data by just text parsing it. So why bother with the wrapper? If the malicious site pulls it in via a script tag, that script tag is still in the DOM and can be accessed as a node right? Which means you have access to the node contents, which means you can pre-screen whatever text is contained in the script tags node and just instr()/regex/char-parse whatever you want. Heck, just store the entire response in a database for parsing later.
The Google “while(1);” solution is heinous. Nothin’ says lovin’ like locking up the users browser. w00t!
My solution would be a two part solution:
1) Limiting requests for sensitive information to POST requests. This is mentioned in the advisory.
2) Salted hashes – salted hashes are your friend. Some kind of security token that you have to pass along with a GET. Generated at the time of the get. Makes it hard to spoof and makes it harder for the malicious script SRC to be created.
via Shelley Powers: