AJAX Under Fire
I don’t know how many people have told me lately they’ve read some article about AJAX security issues that have cropped up recently. Here’s the deal.
AJAX by itself isn’t a security threat. The threat comes in the form of compromised websites, compromised plug-ins, and generally running software that you shouldn’t trust. Basically all your traditional security concerns. The interesting part here is that AJAX provides a thin user interface shell around the traditional request/response architecture, allowing for server requests without the user’s knowledge. This provides the screen behind which these recently uncovered attacks can hide their activity.
Currently the only plug-in that has been called out as having a security flaw is Adobe Reader (formerly Acrobat Reader). Adobe released Adobe Reader 8.0 to address the flaw where an attacker could add a Javascript snippet to any PDF link, causing Adobe Reader to execute the code in the target site’s domain context. This type of attack is generally known as a cross-site scripting attack, or XSS. Read more details about the security threat, and the alert by Symantec and VeriSign here.
So what are the possibilities open to an attacker, once they are able to include scripts in your favorite sites? Since Javascript is not a strongly-typed language, it uses a prototype structure to mimic class and object (OO) constructs. You are fully able to add a function to a “class” at runtime, propagating the change automatically to all objects of that class.
For example, lets say we wanted to add a simple function to all strings. We could add a new function like:
String.prototype.reverse = function() {
var out=""; for (var i=this.length-1;i>=0;i--) out+=this.substr(i,1);
return out;
}
Once this line of code is run, all strings already created (on the current page) already and in the future will be able to execute the new reverse() function. This isn’t a very threatening function, but let’s take another look at prototypes. You saw how easy it was to add new functionality to a built-in Javascript class. Here is a more nasty example of replacing the send() function on the XMLHttpRequest class:
XMLHttpRequest.prototype.sendOld = XMLHttpRequest.prototype.send;
XMLHttpRequest.prototype.send = function() {
// send all the information to the evil database
MyEvilClass.mirrorPost(this, arguments);
// call the original function so you can't tell the difference
this.sendOld.apply(this, arguments);
}
There are other, less obvious and much more complex issues with regards to how browsers treat HTTP requests. The news.com article has a link to a PDF (hah!) that discusses the prototype hijacking I’ve demonstrated above, along with details about cache poisoning and HTTP request splitting. Both of these require broken browsers to function, and IE at least has known vulnerabilities with regard to cache poisoning.
To sum this all up, AJAX and Javascript can be hijacked by using untrusted sites, or allowing untrusted code to run on your computer. However, this is not a new concept - you should always be careful of what code you allow to run on your computer, including what sites you visit.
Update: Stupid wordpress changed my double minus in the code examples to em dashes, so I converted those code examples to use the [code] tag and a [blockquote]. (should look okay now)
Tags:
Post a Comment