AJAX May Be Considered Harmful

87C751 writes "Security lists are abuzz about a presentation from the 23C3 conference, which details a fundamental design flaw in Javascript. The technique, called Prototype Hijacking, allows an attacker to redefine any feature of Javascript. The paper is called 'Subverting AJAX' (pdf), and outlines a possible Web Worm that lives in the very fabric of Web 2.0 and could kill the Web as we know it."

Comments

"Considered Harmful"

[JoshJ]

Javascript vulnerabilities will stop people from using AJAX just like Word vulnerabilities will stop people from using Microsoft Office.

A bit over the top...

[Sloan47]

"...and could kill the Web as we know it." Oh come on! Isn't that exaggerating a tad? Obviously with some browser patches and more secure server code, the problem is solved. Gotta love sensationalism!

notabug

[QuoteMstr]

This paper is absolutely ridiculous, and its author is scaremongering --- if you have access to a site's scripting system via some cross-site vulnerability, then you don't _need_ to subvert an object's prototype to change its behavior. If you're relying on client-side code of any sort, be it written in Javascript or C, for security, you're up a creek without a paddle anyway. Oh nooes, man in the middle proxy attacks! Oh noes, browser bugs allowing javascript to leak outside its security context! There is no security vulnerability in this paper that hasn't been known and worked around for years. I'm wondering what kind of agenda the author has in writing this, actually.

Re:notabug

[stonecypher]

Would you let me know what's new in XSS? All the paper describes are pedestrian ways to sniff info out of a site via existing XSS exploit.

The thing which is novel in this paper is the delivery mechanism, specifically by fundamentally replacing parts of javascript to carry attacks in what would otherwise be quite clean and legitimate code. The only parallel I can think of is the embedded-in-compiler attack that was referred to by the Guy Steele era TNHD as "the greatest hack ever," wherein the foreign code installed itself into anything compiled by said compiler, including new iterations of said compiler. (By the by, I can think of several hacks I think are better; I just mentioned the phrase because most people know to what that refers.)

And XSS is by no means new, or "fundamental flaw" of JS.

I'm not sure why you keep talking about XSS. XSS prototype overloading attacks are just his first example of something you could deploy over his new attack vector. The paper isn't about the XSS attack at all. It's not the payload he's talking about, it's the delivery mechanism. You might consider re-reading. I mean, come on, he even cites someone named "S. Di Paola" (near the top of the second column on page three of the PDF) as the person who came up with the XSS attack he uses as an example, and the XSS attack starts right after the header "advanced example". Why are you suggesting he claimed that was new?

As far as whether prototype overloading is a fundamental flaw of javascript, from the security perspective the current implementation most certainly is. There is no mechanism to identify whether a fundamental library feature has been replaced, or whose implementation you're using. There is not yet an existing mechanism by which an application can defend itself from this kind of attack; this must be defended against by the runtime environment instead, and there are not currently any runtime environments which defend against this sort of thing. Indeed, some of the JavaScript libraries I use rely on that those features are replacable (specifically prototype, moofx, behaviour and dojo, though I know of quite a few other libraries which do it too.) MooFX adds a ton of new features to fundamental things like Objects, Arrays and Strings that I use all the time.

The same mechanism Moo uses to extend things could be used to extend bad things into place. The XSS attack is just an example. It's the extension he's talking about. It wouldn't be hard to "extend" a "logging" mechanism into XMLHttpRequest; indeed I did that once as a debugging tool. What if said logging mechanism logged to a foreign server? There are a million ways to exploit this.

When XSS can occur, it's an implementation flaw of the browser and/or site, and by no means "fundamental" as it's usually fixed in the next point release or site update.

You seem to have entirely missed the point. The thing this paper describes is an attack mounted by a malicious site against later sites in the user's browsing path, not an attack mounted against a site with a flaw. This attack leverages a flaw in current browser implementations of JavaScript in such a way that there need not be a flaw in the remote site, and it is neither possible for a remote site to detect or resist such attacks.

The fundamental flaw is not in Javscript. It's in current implementations of Javascript. You are confusing mechanisms and targets. Yes, the target of this attack is other sites, but the mechanism has nothing to do with the target, and there's nothing the target can do. It's a browser-side attack.

Fundamental would mean it can't be fixed

Yes and no. It's fundamental *to* *current* *implementations* of the language, not the language itself. So yes, it cannot be fixed, *in* *current* *implementations*; it requires a minor new implementation strategy on the part of browser vendors. This will end up requiring a security patch to all browsers (and probably three to IE.)

and if you BS detectors aren't screaming by his paper, you're more gullible than you suspect.

Please re-read the paper. You seem to have missed the point.

Re:notabug

[suv4x4]

As far as whether prototype overloading is a fundamental flaw of javascript, from the security perspective the current implementation most certainly is. There is no mechanism to identify whether a fundamental library feature has been replaced, or whose implementation you're using.

Repeat after me: client-side, interpreted language.

You're loading SOURCE CODE on a machine you DO NOT CONTROL.

In other words, the fact you can "hijack" prototype methods is not a major discovery, since you can actually modify the actual *source code* itself, the classes instantiated can be replaced with other classes, variables can be read and written, instances can be destroyed and replaced.

This is what "scripting" is about. If you don't like it and you're juggling with sensitive info on the client side, there's only one option: not allow XSS by carefully validating scenarios where this may occur (such as displaying poorly sanitized customer data on public pages).

I guess some people still have some difficulty comprehending that anything in JS is subject to change on the client side.

Re:notabug

[tomhudson]

I guess some people still have some difficulty comprehending that anything in JS is subject to change on the client side.

A good example is writing your own proxy to fetch a site, then inject your own scripts into it before feeding it to your browser. Block ads, replace the body.onLoad() that calls a bunch of popups, rewrite all the urls, etc.

Gee, maybe I should write up a fancy paper on how I did it, say its the "latest attack vector" or some other nonsense, and pimp myself as some 133t s3cur1ty xp3rt.

AJAX != the web

[Anonymous Brave Guy]

The paper is called 'Subverting AJAX' (pdf), and outlines a possible Web Worm that lives in the very fabric of Web 2.0 and could kill the Web as we know it.

Well, considering that AJAX is used on only a tiny proportion of web sites, and often not to particularly good effect, I'd say that's a bit of a silly claim. In any case, AJAX often suffers from the same flaws as pseudo-web technologies like Flash before it: lack of bookmarkability, breaking back buttons, etc. These are far more likely to doom it than any random security flaw.

Re:Horeshit.....javascript is crap but....horeshit

[cnettel]

Python also allows on-the-fly redefinitions, which is blamed here. Generally, the choice of scripting language is not the problem here. Most "Javascript" bugs translate directly into VBScript if you're IE-masochistic (or Perlscript, if you've managed to install that and trick IE into running the engine for it). The problem is in the DOM, what objects might theoretically be exposed, and how it's crucial that some part of the browser can access them, while others should not. After all, in Mozilla, the whole UI is held together by Javascript, running in basically the same engine, but a different sandbox. The situation with the IE scripting environment is quite comparable.

Re:Horeshit.....javascript is crap but....horeshit

[smittyoneeach]

What we are seeing now is a push way beyond its original intended scope.

Name a Turing-complete programming tool which has not seen this.

I throw in the qualifier because, other than stuff like regular expressions and SQL, which are not Turing-complete and have blissfully narrow scopes, everything else has seen javascript-acular scope creep.

Here, have an httpd written in PostScript: http://public.planetmirror.com/pub/pshttpd/

Perhaps not being Turing-complete is a left-handed virtue.

Circumventing the XSS protection of AJAX

[KalvinB]

JavaScript S on Domain A needs to access the server side script on Domain B. All S has to do is AJAX to a local bridging script which forwards the request using CURL,LWP, etc to B. The bridge then feeds the response to S. S has no idea that the AJAX request went to another domain. As far as B knows, A is just a web visitor.

Since AJAX runs on the client side it's not possible to whitelist IPs and Referers can be spoofed.

As with every client/server app the client can never be trusted.

Ajax IS considered harmful.

[Vo0k]

Ajax sucks. Not because of security.

The article Why Ajax Sucks (Most of the Time) is a nice spoof of an old article about frames. Despite being a spoof, the word 'frames' replaced by 'ajax' and little else changed, it's surprisingly accurate and nicely outlines WHY it's harmful.

Meh...

[Anonymous Coward]

I'm a professional web developer, amd have been using XMLHttpRequest (ajax, if you really want) for the past two years in a large number of web applications. Having taken the time to actually carefully read (not skim) the eight pages of this document, I have only one thing to say: I want my 15 minutes back.

This is a paper about more efficient ways of being malicious, but they only work if you can be malicious in the first place.

You know what? If a malicious user can insert script to be executed for another user, I already have an unacceptable problem! I really don't care if that unacceptable problem is now 10% worse than was generally realized before.

Re:Have you ever tried to deploy an AJAX applicati

[Zarel]

Have you ever considered that those could all be badly programmed? I mean, I could write a Java program that took tons of resources, ran really slowly, didn't allow text selection, and more. And I could write an Ajax application that ran far faster than the equivalent non-Ajax one.

As for your specific case of a text field being unhighlightable, I suspect that has to do with the Ajax application using onSelectStart to disable selection within the page (sometimes as really crappy DRM, sometimes because click-and-dragging is needed for some other functionality), and not knowing how to re-enable it for the text field (which is something I, a 16-year-old, know how to do). Problems like the ones you describe are usually caused by vendor incompetence.

Ajax, by itself, can't possibly cause any of the problems you describe. All it is is a system by which Web pages can interact with the server without needing to load a new page. This means:

1. Less bandwidth is used because you don't need to load layout information for each page. Consequently, it's faster than non-Ajax applications.

2. The Back button goes to the last page, as opposed to the last action, which is a good thing for true Web applications, since the Back button usually causes tons of problems (Ever seen "DON'T PRESS THE BACK BUTTON OR YOU COULD ACCIDENTALLY PAY FOR THIS PRODUCT TWICE"?).

3. If coded to do so, the server can relegate translating raw data into a human-readable HTML layout to the client. This is usually done because the client usually has many processor cycles to spare, while the server doesn't. (This also doesn't take much processing power, and should be unnoticeable to the client)

4. You have more control over page transitions, and you can have things like "Loading..." messages while the data is being fetched from the server (as opposed to traditionally, where the only indication is "Loading..." in the browser status bar and the top right loading animation, and then, when it loads, the page goes white and the new layout is loaded.)

Those are the only differences. So, in reality, Ajax is superior in every way for Web applications, and the problems you describe are caused by bad programming practices, and would've happened whether or not they were written in Ajax.

Re:Greasemonkey?

[suv4x4]

There is one problem with this: Cross site checks don't apply.

You didn't test that and just assumed it's true I guess. But if they applied, and each page context runs in its own sandbox with its own version of String, Number, and so on, you'd sound pretty stupid right?

Try it yourself, the prototypes are NOT shared. They are not shared even among two page tabs on the same domain.

In fact not shared even among two instances of the SAME PAGE.

Embarassing, I guess, for all modded 5+ claiming this on this article.

What's really going on here.

[Animats]

Nobody is explaining this right.

JavaScript has a security policy. The security model is that 1) scripts can only talk to the site from which the script came, and 2) scripts can only alter documents from the site from which the script came. The security model is enforced only at a few points, notably the XMLHttpRequest object and at points where Javascript stores into the document object tree.

Other than those few enforcement points, JavaScript objects in the same browser instance can communicate freely. This offers a number of potential exploits, some of which are listed in the paper.

If the security model is tightened up, prohibiting all intercommunication between Javascript objects from different sites, "mashups" no longer work, so it's too late to tighten this up without breaking some popular sites.

This is going to be hard to fix without breaking existing programs. Javascript has a very weak concept of what's immutable. It might work to mark functions as "dirty" if changed once loaded, then forbid "new" on "dirty" functions. That would prevent changing the base instance of a class without breaking too much else, and would fix this new vulnerability. But it wouldn't fix all potential vulnerabilities in that area. As long as multiple scripts share global variables, there's going to be potential for trouble.

Maybe "https" pages should be locked down more. "Secure" pages should be single source - everything has to come from one specific domain address. No frames, no cross-site anything - one secure site per window, and no shared data with other pages whatsoever. That's a start.

Re:Horeshit.....javascript is crap but....horeshit

[pestilence669]

JavaScript has gotten a pretty bad rap. I think unfairly. People tend to pigeonhole it as a "web" scripting language, which is certainly how it started off, but it's much more capable than that. Even Java started off as a "Web" language (with ambitions of world domination). Both have matured in the past decade.

JavaScript has all the niceties of modern OO languages and more, because it's prototype-based. All that's needed is some discipline, because it also allows you to write exceptionally ugly code. Both Perl and C++ are the same way. You can drop into procedural hell any time you like. In C++, you can even resort to goto statements or drop into assembler.

In JavaScript: you can have static class methods & members, encapsulation (private methods & such), multiple layers of abstraction, and features even Java can't handle, like: multiple inheritance, closures, reflection, and dynamic typing. Not to shabby for a crappy little scripting language.

Any nice OO language (like Python, Smalltalk, Ruby) in a browser sounds wonderful... but it'll never work for very long. Do you really think that Microsoft could keep proprietary language tweaks out of their implementations? It happens with JavaScript all of the time. Netscape added proprietary features because it was THEIR language. AFAIK, that stopped as soon as it was offered up for standardization.

Microsoft has continued to make proprietary "contributions" to JavaScript. If it weren't for them, everybody's JS implementations would work together in harmony. Microsoft alters their HTML, XML, CSS, and C++ implementations in ways that prohibit cross-platform compatibility (what a surprise). They'll do the same to Python.

Re:Have you ever tried to deploy an AJAX applicati

[Zarel]

Sure. And the very "design" of AJAX encourages such poor development to occur. The fact that virtually every AJAX application is problematic shows that the problem is not with the developers, but with the technologies those developers are trying to use.

Have you missed the portion of my post where I explained exactly what Ajax was? It's just a JavaScript library that allows the page to communicate with the server without clicking a link and bringing up a new page. How does that encourage poor development?

And I have to dispute your claim that "virtually every Ajax application is problematic". I've seen plenty of places where Ajax is used effectively - Google Maps and GMail, to name two. Maybe in your experience, they are, but, as they say, the plural of "anecdote" is not "data".

Now I understand why you don't comprehend anything about how ineffective and pathetic real development is when using AJAX. Come back when you've had to deploy a real system, jimbo. You know, where it actually has to work. If you brought up an AJAX "solution" at the firm where I work, the rest of us would laugh at your sorry ass for suggesting a technology that fails in so many obvious and integral ways.

Care to give examples of these "obvious and integral ways"? I have deployed real systems, and they have worked, and I haven't come across any of the problems you've mentioned.

Re:Have you ever tried to deploy an AJAX applicati

[kcbrown]

Are you saying Java apps work poorly?

Performance-wise, yes. In terms of resource usage, yes. We have deployed a number of commercial groupware systems implemented in Java, as well as several implemented in Perl. We have found the Perl systems to perform far better. We'd take the time to try to figure out why the Java solutions perform so poorly, but it just wouldn't be feasible. The Perl solutions meet our needs more than adequately, so we use them.

There's a reason Java applications seem to be, on average, slower and more heavyweight than their equivalents in Perl: it seems to encourage complexity.

The typical Java stacktrace you get when something goes wrong is, in my experience, some 30+ levels deep. That's ridiculously high.

That means that Java applications are built with class upon class upon class upon class, to a ridiculous degree. The amount of subclassing that happens in a typical Java program is much worse than any other language I've seen, by a factor of 4 or more.

It's so bad that you have to use a language-aware tool like Eclipse to keep track of it all. Without the ability of such tools to track the class relationships, such programs would literally be impossible to maintain.

And what does all that extra complexity buy you? Why, nothing at all, actually. The software isn't any easier to develop, debug, or maintain than it would be in any other reasonable language. In fact, I would argue that it's harder to maintain because of the additional complexity.

The choice to make a program more complex is one that must be made very carefully. Java somehow seems to encourage developers to increase the complexity of their programs. Whether it's because of the language (which includes the class libraries in this case) or the development tools I cannot really say. I suspect it's a combination of both.

Because of these issues, I've been completely underwhelmed with Java as a development and execution platform. As a language it has some strengths, as all languages do, but I don't find any of those strengths particularly compelling, and find the weaknesses to be very significant.

Java actually turns out to be a reasonable language to write programs in, but it requires an extreme amount of discipline and you don't get a whole lot in exchange. If I want my programs to be maintainable, I'll write them in Ada or something.

Re:FUD

[hobo sapiens]

When it comes to sites using AJAX, such bookmarks are often not possible.

My. Goodness.

Look. It depends on HOW AND WHERE you use AJAX. Jeez!!! Can we please put this to bed? Yes, if you design a whole flippin site that is one page with a zillion AJAX calls, well, gee whiz! Bad idea! But, if you use your brain and use it only where it ADDS VALUE then maybe, just maybe, it's a good thing? You think? Just because beer is a good thing doesn't mean you pour it in your gas tank, use it to make Kool-Aid, or bathe in it. I am SICK (can you tell?) of people misusing technologies and then blaming the technologies! Stop it!!!

Re: first post

[Crayon Kid]

[..]if an injection mechanism is available.

Therein lies the cruft of the issue. XSS is the culprit, not Ajax, not prototyping, not JavaScript itself. It all comes down to incompetent developers allowing visitors to inject JavaScript that other visitors will execute. Period. Once custom JS is executed all bets are off, assume the worst.

This is an extremely basic point in security of any kind: once the attacker is executing code inside your system, that's bad. Nevermind that fact that other limiting factors will mitigate the range of the attack (browser-only for JavaScript, account-permissions-only for other attacks). Most efforts should be made to prevent intrusion, not to limit damage after the attacker is "in".