AJAX library security advisory

Fortify identifies JavaScript vulnerability in AJAX apps

You can read the advisory here(pdf)

JavaScript hijacking can be carried out “if a victim is tricked into going to a Web site of a bad guy, and this site can start loading JavaScript from the bad guy,” Chess says. The end effect is that the bad guy takes over the browser using JavaScript as the data transfer format and poses as the victim. “This is a new class of vulnerability and a pervasive problem for almost everyone who’s built rich AJAX applications,” he says.

The general idea is that if your web application sends down un-encrypted JSON objects whose only security check is that the request is coming from a known client (e.g. one with a session id), then malicious web pages can request that JSON object directly via a script tag. It’s a work around in the same-site rule that the JavaScript sandbox has. The same-site rule states that XMLHttpRequest can only make requests to the same domain as the web page. This is to prevent one cross-site scripting attacks. The work around is that the “src=” attribute can point to ANY domain and load the JavaScript from there. It’s how Yahoo is offering to host their YUI library for anyone.

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: