Ajax [in]Security

When jOHN first accused me of being Captain Technology Curmudgeon, I was a little peeved because I’ve been of the opinion that its more how to make Ajax secure and not if it can be made to be secure. How can THAT stance be curmudgeonly? It was Gary that took the stance that Ajax is to be avoided.

So, I set about writing a talk for SD West about how to write Ajax applications that aren’t insecure (I do hate double negatives, but with security one can never really state that something IS secure). I based my talk on work I’d done with our client, research from the Web and my own experience writing Ajax.

At first, things seemed pretty encouraging. Ajax seemed to heighten the existing problems on the web. For example, there was the problem of good, API design for all of the additional services and the associated need for solid input validation and output encoding (albeit encoding for XML and JSON instead of XML). This all seemed pretty tractable because there are known solutions even if those solutions may not be wide practiced yet.

I should have sensed that the party was starting to end when I ran across “dynamic script tags”. I’m not sure why they are called “dynamic script tags” and why they aren’t called “subverting the JavaScript sandbox”. Here’s the deal. Say, I want to “mashup” content from two sites. Tres Web2.0. But the XMLHTTPRequest object limits me to downloading content from a site other than the one that supplied the calling JavaScript. So, instead of doing something more secure like doing the mashup on the server, why not just use an HTML tag that isn’t restricted by the same JavaScript sandbox rules.

In my younger days, I would have said “Nice hack”. Now, I just shudder because this subversion of the JavaScript sandbox is being promulgated on the Web as a feature instead of the rude flaw that it exploits. Okay, so this is slightly curmudgeonly…

I then found a paper by Stefano Di Paola and Georgio Fedon that described an attack called Prototype Hijacking. Now, “Prototype” isn’t in reference to the popular JavaScript framework – it’s in reference to the fact that JavaScript uses prototype-based inheritance rather than class-based inheritance. Due to the dynamic nature of JavaScript, I can change the prototype for any JavaScript object. Most excellent. Let’s change the prototype of, say XMLHTTPRequest. Maybe the “Send” method?

So, securing Ajax applications is going to be harder than I thought. I’m not sure how to prevent Prototype Hijacking – well not yet at least. So, jOHN, how can THAT be curmudgeonly?

Technorati Tags: ,

One Response to “Ajax [in]Security”

  1. Romain Says:

    I would say that there is no real way to prevent prototype hijacking if you can have a XSS vulnerability in your application.
    Btw, prototype hijacking is quite okay to prevent, with basically no remote script inclusion, but the worse is coming with JavaScript 2 operator overloading… With that feature people would be able to totally change the meaning of your script.

Leave a Reply