This article was posted to a mailing list (jquery discussion) I'm on and was quickly labeled FUD by some participants. It links to a
javascript hijacking pdf that makes some moderately good points.
What they are calling Javascript Hijacking is a subset of a vulnerability that has always been there. This vulnerability effects ajax calls among other things, but calling it new on that basis is...??
I've heard this called session riding or cross site request forgery. If I know bank of america's URL for a transfer funds service, I can code that into my page as the source of an invisible iframe. Should you visit my page WHILE logged in to your bank of america account, the browser will activate that page AS IF you had visited it directly.
The additional vulnerability with services that provide a JS (including JSON) interface is that not only can you execute an action using CSRF, you can look inside the package that's returned (normally browser restrictions would let you create the iframe and point it at the service, but not read the results). This is because JSON payloads get executed when they are linked into a page as a script, at which point the resulting objects are available to be read by JS running on the page (even a hostile page).
The PDF describes a technique for enforcing the same domain policy on javascript. If you put an infinite loop at the start of the javascript, then you can request that javascript via XHR, strip the loop code off the front, then eval the resulting string. If you grab that same JS in a script tag, the loop will run and the data will never show up to JS running in the page... in fact all execution on the page will stop. This sounds like a good practice if you don't have any other protections against session riding.
Better protections against CSRF attacks are available, namely verifying referrers, and using sessions and one time tokens on the server side as discussed earlier. Javascript hijacking is blocked by everything that blocks session riding.
Dated: 04/03/2007