AJAX May Be Considered Harmful 308
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."
"Considered Harmful" (Score:5, Insightful)
A bit over the top... (Score:4, Insightful)
notabug (Score:3, Insightful)
AJAX != the web (Score:4, Insightful)
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 (Score:5, Insightful)
Re:Horeshit.....javascript is crap but....horeshit (Score:3, Insightful)
My problem? I wish some other name than "JavaScript" had come around, so every JS book and every JS idiot didn't need the paragraph about "Javascript is nothing related to Java".
100% FUD (Score:1, Insightful)
Even if JS suddenly stopped working outright today, web wouldn't change a whole lot, from what we know it.
Apparently the guy just comes from compiled languages like C++ where you can't modify a class once its defined, and he decided to spread some FUD to express his disgust with dynamic languages.
I guess he was disappointed he can't safely store his server root passwords in his JS files.
Re:Horeshit.....javascript is crap but....horeshit (Score:5, Insightful)
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/ [planetmirror.com]
Perhaps not being Turing-complete is a left-handed virtue.
Circumventing the XSS protection of AJAX (Score:4, Insightful)
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. (Score:4, Insightful)
The article Why Ajax Sucks (Most of the Time) [usabilityviews.com] 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.
Re:notabug (Score:5, Insightful)
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.
Meh... (Score:3, Insightful)
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 (Score:5, Insightful)
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:100% FUD (Score:2, Insightful)
For your information, just skip to the last page of the paper. It describes both of the paper's authors. Probably the main author of the paper is Stefano Di Paola and his brief biography is given in the paper, you don't even need to look it up. He's a professor at the University of Florence and has found many dangerous vulnerabilities in MySQL and PHP. It also looks like a fairly well researched paper (didn't read all of it though). Obviously, you'd have to verify his bio to be 100% certain that it is true, but I have a feeling it is if he's a respected security expert (which would explain him presenting at 23C3).
You may also find this nice little gem as the last paragraph: Certainly, non of the end of the world scaremongering you attributed to himself. Somehow, I have a feeling that this guy knows more about this stuff than you.
Re:notabug (Score:4, Insightful)
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:Greasemonkey? (Score:5, Insightful)
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.
You're confusing protocol and applications. (Score:0, Insightful)
Very interesting, seeing has how AJAX has nothing to do with your server-side technology whatsoever.
Excuse me? AJAX is intimately involved with server-side technology. After all, there has to be some recipient on the server-side to respond to the AJAX requests sent by the client's Web browser. You can rarely build a useful AJAX application without involving a server of some sort. When designing an AJAX application, one must take into account server resource usage. Unfortunately, it often proves to be greater than when one is using a more traditional Web application development approach, including CGI scripts, PHP, JSP, etc.
Again very interesting, seeing as how AJAX itself has nothing to do with the way users interact with form elements.
Again, you're confusing protocol with applications. We're talking about AJAX applications here, many of which do end up using JavaScript to mess around with UI elements. This often leads to non-standard behavior which confuses users to no end.
your and your team have no idea how to actually code Javascript/AJAX/whatever, and you picked crappy packages off the internet and expected them to Just Work out of the box the same as your custom built solution.
Between the 9 of us, we have around 95 years of Web development experience. We know what we're doing. And we can also identify poor technology, AJAX being the latest example. Had you read my post, you would have read that we even worked with the vendor of one of these commercial products to improve its performance with our installation (to no avail, I may add). I'd like to name names, but I don't think I'm in the position to do so right now.
What's really going on here. (Score:4, Insightful)
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 (Score:4, Insightful)
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:notabug (Score:2, Insightful)
Re:notabug (Score:4, Insightful)
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.
Re:Have you ever tried to deploy an AJAX applicati (Score:4, Insightful)
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".
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:FUD (Score:3, Insightful)
I'm sorry, but I have to disagree. AJAX is NOT a great technology. It's a perversion. It bends HTTP and HTML to do things they were never meant to do. And because of that, it's not really surprising that it has so many huge problems. Not being able to bookmark or use the back button? Those are gigantic problems.
If anything good can be said about AJAX, it's a curiosity. It's certainly amusing that it can be done, but "great technology" it is not.
Re:"Considered Harmful" (Score:3, Insightful)
I really don't see what there is this huge hatred towards Javascript. Javascript and now AJAX (which is just a method of using JavaScript) Is actually one of the best combining server and client side applications, that will work multi-browers and multi-platform. As well the band with savings can be good because you will only send the information you need once. Things like Flash, JavaApplets, Active X are good examples of a bad attempt to make the web more application like, because they all require either special browsers, 3rd party plugins from companies who own the rights to it and they are in a binary format which for many cases makes the application a lot bigger and more bandwidth. JavaScript with AJAX method actually really allows Web Based applications to work well and be used by people wether they are running Linux, OS X, Windows, FreeBSD or almost any other Operating System. As Well AJAX development can be used on any web server. It is actually a very liberating development platform. Yes it is ugly development, and feels kinda like a hacked method of working. But so far it is the best that we have without having to go 3rd party for an extra layer of processing.
Re:FUD (Score:2, Insightful)
People also find it important to be able to open multiple pages of a site in multiple browser tabs concurrently. AJAX sites often do not allow for this, or run into problems if it is attempted.
It's also important that an AJAX site not cause a browser to repeatedly send out requests to the point of the CPU being maxed out, and the web browser becoming unusable.
There is a lot of talk about "well-designed AJAX applications", but we never actually end up seeing such a beast. You talk of GMail. I use the non-AJAX GMail interface mainly because the AJAX interface does not allow me to open emails in new tabs.
When it is very difficult, if not outright impossible, for virtually all developers to come up with even just a decent application using a specific technology, I do blame the technology. It obviously impedes the ability of even the best developers, presenting problems that cannot be avoided or worked around.
AJAX is to web development what a cucumber would be to the guy who nails in railroad spikes. It's fucking useless. The railroad builder will smash cucumber after cucumber on the railroad spike trying to nail it down, without any usable results in the end. The same goes for web development using AJAX.
Re:Have you ever tried to deploy an AJAX applicati (Score:2, Insightful)
From what I understand, AJAX would be a bitch to program right, and comes with a whole lot of issues that you describe for the programmer to sort out. But there are some clear success stories - gmail being the obvious one. Gmail started out with a couple of these issues, but google have been steadily fixing them and now it's slick and a great user experience.
And this is rather off-topic since it has nothing to do with the security vulnerabilities in TFA.
Re:"Considered Harmful" (Score:1, Insightful)
Are you using a different definition of good than I am?
Just for clarities sake, I think I will use webster's definition as a reference:
1 a (1) : of a favorable character or tendency
Have you ever used the linux flash plugin? Things tend not to work. Have a nonstandard soundcard? NOPE. Not gonna work. Want to view things from the latest version of flash? Try again later. Want to use a non mozilla browser? There might be a compatability layer you could try. Have a 64bit processor? Run your browser in 32bit. Want to be guaranteed future updates? There is a possibility, we even have a small team. Don't have an x86 processor? Use an emulator or something.
Re:FUD (Score:2, Insightful)
Re:Have you ever tried to deploy an AJAX applicati (Score:2, Insightful)
Re:Have you ever tried to deploy an AJAX applicati (Score:3, Insightful)
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 (Score:5, Insightful)
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:FUD (Score:3, Insightful)
We are talking about websites/webapplications here. The question is not whether you can and want to install it, but whether the customers/target group of that website want to/can/will install it -- and the answer is no, they won't. Even the most trivial install will only be made by a small percentage of people.
More than 90% of all webusers already have an AJAX-capable browser though.
Re: first post (Score:5, Insightful)
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".
Re:Have you ever tried to deploy an AJAX applicati (Score:3, Insightful)
I'll take a stab at this. The problem is that it encourages people to write substantially more complex front-end code in javascript than was ever attempted prior to the development of AJAX. And front-end javascript is notoriously difficult to do right: there are a lot of browser incompatibilities that need workarounds, and many things that should be common in an application are actually very difficult to achieve, primarily because Javascript wasn't designed for this purpose -- its design goal was to allow small page modifications to be performed at the client, not to allow people to produce complete user interfaces. The fact that it is restricted to a single thread of execution and doesn't have a wait-for-event primitive makes some complex designs very hard to implement. Its handling of common user interface elements is basic and often difficult to work with.
All of these factors combine to make AJAX development substantially harder than equivalent development in more friendly environments (e.g. Java app development, native Windows, Linux or MacOS app development, etc.).
Re:It's clearly not an ad hominem attack. (Score:3, Insightful)
I have also given plenty of evidence that those companies don't know what they're doing: They've somehow managed to make an Ajax application many times slower for the client and server, as well as take up much more bandwidth, the exact opposite of what Ajax is meant to do.
What we're talking about here is even towards the low end of the spectrum. The AJAX applications we attempted to use were only being used by about 8000 people spread throughout our offices in the northeastern US. You won't understand a deployment even of this small size until you've actually done it one or twice, kid.