Monday, January 8th, 2007

Subverting Ajax

Category: Editorial

A bunch of hub-ub has been created over a presentation at the CCC conference called Subverting Ajax.

The FUD has been interesting to watch. Early in the article they discuss how JavaScript is a prototype-based system which is a ‘flaw’ as people can do things like:


  1. XMLHttpRequest.prototype.send = function (pay) {
  2.    // Hijacked .send
  3.    sniff("Hijacked: "+" "+pay);
  4.    pay=HijackRequest(pay);
  5.    return this.xml.send(pay);
  6. }

The article does do a good job in explaining some of the dangers, but doesn’t mean that all Ajax is bad. Much as SQL injections are bad, but if you do a few smart things you will make sure that there is no surface for them.

Alex Russell of Dojo has a great response over on his blog:

What really makes me sad though is that the work of folks like H.D. Moore, Thor Larhom, and Jeremiah Grossman gets lost in the noise when chaff like this is published. By not providing an honest evaluation of the real-world potential of a threat vector, the authors of a paper like this create a sort of seismograph that can’t tell magnitudes, only number of things shaking. Without magnitude information, an instant market is created for people to stand on the tops of roofs and yell down how bad it is (or in this case, how bad it could have been had they not been valiantly standing there).

Threat information is only valuable as when there is enough data about it to manage and mitigate risk. Yes, security problems are real, and web app security problems aren’t going away any time soon, but without level-headed analysis of the threat vectors, the real-world risk profiles, and the root-of-trust that is being attacked there is very little reason for clients to view the security community as anything but a freakish collection of opportunists, wolves, and disillusioned techno-utopianists. Accurate data builds trust, and trust builds a relationships that allows you to effectively mitigate risk. It’s high time that the security industry developed a code of ethics that prevents FUD-slinging. OWASP could even lead the way although I suspect there’s not a chance in hell of it happening.

What are your thoughts?

Posted by Dion Almaer at 12:57 pm

3.4 rating from 21 votes


Comments feed TrackBack URI

Comment by Alex Russell — January 8, 2007


This my firs comment :) I would like to know how you get the code to show up so nicely in your post, it there a plug in for this?


Comment by Emil Davtyan — January 8, 2007

Great post by Alex. Thanks for that.

I need to read Grossman’s latest post a bit more carefully… but I’m confused (perhaps others can add some more insights to help clarify for me)…

Grossman’s latest seems to be a different stance than his previous post on WhiteHat’s site. Before he and WhiteHat effectively stated “Ajax presents no inherent insecurity” (link here:…

now this latest on his blog he says “Web browser security is broken. Completely shattered.”

I understand there’s a distinct difference in topics here between the Ajax paradigm not being inherently flawed, and commenting on the browser’s security, but yes, this recent commentary on browser insecurity seems to be a lot of FUD more than facts and data. Thanks for providing some more insight with your post.

Comment by Mark Holton — January 8, 2007

I still don’t get it. I mean, I get the prototype thing and I understand the code above, but I’m trying to think how this could really happen.

First off I’m a developer for enterprises and our users are not just anyone who can sign up and log in. It’s all corporate and companies use us because they want to. I think it’s important to say that becuase first and foremost, in order for someone to submit a hijacked Ajax request, they’d have to be one of our customers. Quite possible I suppose, but unlikely.

Second, all our Ajax requests are first checked for the proper authentication. If the credentials are invalid, then that’s as far as things go. So this sorta gets back to my first point which is only our clients have the proper creds to access the logic on our servers.

That said, I’m still not certain, even if someone was authenticated in our system, how an exploit would happen. I mean, I see the theory of changing things, but how could someone, say, change a JS method I might have for a specific call – say to look up a contact – and then somehow put it on the server so it would be available the next time to other auth’d users? Or is this not the right way to look at it?

I dunno, guess it’s nice in theory and stand-alone, but I don’t see how it would fit into an actual real running app. Maybe someone could shed some light on this.

Comment by Jason — January 8, 2007

So wait … client-side application logic can be hijacked? This is news. Look, I’m back in 1997. That being said, you would still have to provide some method of insecure user input for any of this to matter, and hopefully we all do that by now. We do, right?

Comment by Dan — January 8, 2007

I was kind of appalled by the announcement of this “great threat”. This is a well known behavior which has been repeatedly used in the javascript community. As any other idiosyncrasy of a programming language, it needs to be evaluated as part of a security review.
But I have a hard time believing that the authors of this presentation are issuing this warning in good faith. They surely must know that nothing in the paper is new. It seems to me that they are only seeking sensationalism.

Comment by Julien Couvreur — January 8, 2007

info on the the code display can be found here:

Comment by Eric Pascarello — January 8, 2007

Is ajax the problem or is javascript itself the problem?
And if it is, what are we supposed to use instead?
Isn’t this just the same old bunch longing back to the good old days when it was just ugly pages with hyperlinks, like my teachers back in school, who thought that anything but ‘pure’ html containing some (boring) research on how to properly format a sentence in chinese or on how rare bugs from outer mongolia has longer antennas, is sent by satan to destroy the world?

“Young man, when I was at your age, I walked TEN miles to school and without shoes and in a icecold blizzard – and by the way – we had noooo stinkin’ javascript running either..”

Comment by mikael bergkvist — January 8, 2007

I say as Homer Simpson did.. “Mmmm, javascript..”

Comment by mikael bergkvist — January 8, 2007

My $0.02 on this:

Comment by kourge — January 9, 2007

Mikael, this is a problem with XSS, nothing more. It basically says “once an attacker can get his JS code to execute in a user’s browser, he can access and change the javascript therein.” A striking revelation…

Comment by Martin — January 9, 2007

This is the general danger in JavaScript, so this is just one of million examples how to manipulate native functions and methods. This one is probably riskier but if you check all JS sources in your HTML such a thing should be the exception. What about some useless JavaScript:

XMLHttpRequest = null;
document.body.innerHTML = ‘Blank site’;
while(1) {

Comment by Andi — January 9, 2007

Leave a comment

You must be logged in to post a comment.