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.

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.

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.

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.

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..”

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: