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."
Summary completely overhyped (Score:5, Informative)
Having skim read the article, it outlines how *if* you can execute malicious javascript for a website you can subvert the AJAX communication so that you can have man in the middle attacks etc.
However once an attacker can execute malicious javascript in the scope of the target website you're toast whether you are using AJAX or not.
I'll make a bold prediction and say that is not going to "kill the Web as we know it" contrary to what the /. article says.
Horeshit.....javascript is crap but....horeshit (Score:2, Informative)
Re:"Considered Harmful" (Score:3, Informative)
Now, I know you said vulnerabilities, but I wanted to point out that some parts of the Office functionality has already been removed this way. Javascript off by default for unknown sites has so far been a "geeky" attitude, the web would certainly change if that attitude would turn into norm.
Re:Greasemonkey? (Score:4, Informative)
This is about the way Javascript implements object oriented programming: In Javascript you don't define classes from which objects are instantiated. In a nutshell, you create prototype objects and new objects are copies of the prototypes. The "attack" is to change existing prototypes. For example, you can add a new function to the String prototype or replace an existing function with your own implementation. Every String object then gets the new function. There is one problem with this: Cross site checks don't apply. A script from one site can't simply communicate with another site, but it can modify the prototypes that the scripts from the other site use and subvert the communication of the other script with its host.
Re:notabug (Score:5, Informative)
page 3
This technique has been found by S. Di Paola and is called Prototype
Hijacking. It represents the state of the art in hijacking
techniques applied to the Javascript language.
page 6
This new kind of attack has been called AICS and has been thought by S.
Di Paola and G. Fedon and developed by S. Di Paola.
page 8
Stefano Di Paola. Senior Security Engineer of proved experience, works
since many years as an IT consultant for private and public companies.
He teaches Database Programming and Information Security at the
University of Florence. Since 1997 is a well known security expert; he
found many of the most dangerous vulnerabilities in recent releases of
MySQL and PHP. From 2004 his researches focused mainly on Web security.
Actually he is part of OWASP (Open Web Application Security Project)
team and he's the focal point of Ajax security for the Italian Chapter.
He is the creator of http://www.wisec.it/ [wisec.it]
Giorgio Fedon. Currently employed as senior security consultant and
penetration tester at Emaze Networks S.p.a, delivers code auditing,
Forensic and Log analysis, Malware Analysis and complex Penetration
Testing services to some of the most important Companies, Banks and
Public Agencies in Italy. He participated as speaker in many national
and international events talking mainly about web security and malware
obfuscation techniques. During his past job he was employed at IBM
System & Technology Group in Dublin (Ireland).
Actually he is part of Owasp (Open Web Application Security Project)
Italian Chapter.
solutions (Score:3, Informative)
If 'Web 2.0' comes to be widely untrusted, it will have to change or die. This doesn't represent any new threat to the web itself. The threats are old and because of their nature have been there from the beginning and aren't going away any time soon.
Re:notabug (Score:5, Informative)
Try reading the paper before lambasting it. The stuff you saw in the slashdot article isn't in the paper. The author of the paper says things like "innovative new attack" and "next generation of server side injection." The stuff about end of the web as we know it is from the slashdot poster. The paper is quite insightful, and the author is almost blase about the whole thing. It's quite clear that he simply believes he's unearthed a new form of attack, and he's in fact quite correct.
Please get off of your soapbox. You're wrong.
Have you ever tried to deploy an AJAX application? (Score:5, Informative)
AJAX applications just aren't solid or stable, for the most part. We tried to integrate a number of them into our network here, and frankly each attempt went terribly. I'd like to think it was just one application vendor or AJAX toolkit that was problematic, but that wasn't the case.
We found a number of common problems with every AJAX application we tried. Just for the record, the applications included three CMS systems, a Web-based email system, two groupware systems, and three Web forums.
The first major problem with one of resource usage, on both the client-side and the server-side. Client-side, many AJAX applications consume far too much CPU time. From our investigation, it was due to the use of poor JavaScript algorithms that'd consume 100% of the CPU in some cases, for minutes on end. The applications "worked", in that they'd provide the correct result. It'd just take them far too long to get it done.
On the server-side, they'd again result in excessive CPU and RAM consumption. For one of the Webmail systems, we could only handle a fifth (yes, 20%) of what our old Perl-based system could. And that was on a quad-core Opteron system with 8 GB of RAM! The Perl-based system was on a couple of 200 MHz Pentium systems, each with 128 MB of RAM. Even after assistance from the AJAX-based Webmail system's vendor, we were only able to handle roughly 90% of the number of transactions of our older system.
The second major problem is that of usability. Many of the AJAX apps we tried didn't play well with browser tabs, for instance. Some even fucked around with text input areas, resulting in copy-and-pasting no longer working. One application even prevented the text within a text field from being highlighted! We thought these problems may be browser-specific incompatibilities, be we ran into this same problem with Firefox, Safari, Opera, and even IE6! After talking with the vendor, they admitted these were known problems, and no solutions were presently available.
The third major problem is a lack of quality. Many AJAX applications are poorly coded and poorly designed. I think the main reason for that is because it's such an unstructured technology. Even competent software developers run into problems that cannot be solved easily, and thus must resort to hackish techniques to overcome these inherent problems.
The fourth major problem was that the users hated the systems. Of the few systems we managed to roll out successfully, the users absolutely hated them. Their complaints were a combination of the above three factors. The AJAX applications would not do what the user wanted. The AJAX applications did not conform to common practices (eg. copy-and-paste, textbox text selection, etc.). The AJAX applications ran far too slowly, even on fast client machines. The AJAX applications just plain didn't work!
All of our AJAX trials were abysmal failures. That's why we're sticking with the existing Perl- and Java-based systems that we currently use. They perform far better on much fewer resources, actually do what the users want, avoid violating the most common of conventions, and they do what they're supposed to. I'm sorry to say it, but AJAX might just be the worst technology I have ever had to deal with.
Re:notabug (Score:2, Informative)
Re:notabug (Score:1, Informative)
The author of the paper says things like "this bug will allow you to run arbitrary JavaScript code in the context of any website, and all you need to do to exploit it is to find a way to run arbitrary JavaScript code in the context of any website".
Plus, half the code they give to hijack the XMLHttpRequest object doesn't even work. Do these guys even know JavaScript? Have they tested it, like, AT ALL?
Re:Non-PDF? (Score:2, Informative)
Seriously, can we mod the OP Flamebait? (Score:5, Informative)
I hate all this crap about "ZOMG, once I can inject javascript into a page, something else makes it totally insecure!!!"
Once someone can inject javascript onto a page, you're toast. The article itself is valid, and isn't complaining about ajax so much as prototyping (despite the title of the paper).
Re:Have you ever tried to deploy an AJAX applicati (Score:4, Informative)
You've stated quite an amount of vagueness there, sir, not to mention this confounding statement:
Very interesting, seeing has how AJAX has nothing to do with your server-side technology whatsoever. Or how about this:
Again very interesting, seeing as how AJAX itself has nothing to do with the way users interact with form elements.
It sounds to me like either 1) you're BSing, which is my actual guess, or 2) 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.
Your problems have had nothing to do AJAX; rather, they have had to do with either your lack of knowledge or your life as a Slashdot troll.
prototype overloading is not special (Score:2, Informative)
I just consider this an efficient use of javascript. It's not enabling anything that couldn't be done already.
The important user data for almost all sites is stored on the server anyways, not being sent over the wire, and if it were, it would require much specific effort to make the data usable.
It's not a new class of vulnerabilities, it's merely a new minor exploit technique of already-existing vulnerabilities. It doesn't decrease anybody's actual security.
Re:Have you ever tried to deploy an AJAX applicati (Score:4, Informative)
I'm going to call bullshit here. An ajax application is not significantly different on the server side than a regular web app. In fact, it is often easier on the server because the server only needs to render a small portion of the result for a given action rather than and entirely new page.
What does "perl based" have to do with it? You could very well have a Perl based (on the server side) AJAXy application.
Bullshit again. You are comparing AJAX with Perl/Java based systems as if there was any comparison to be made. Saying Perl based systems are better than AJAX systems is like saying roads are better than cars!
But thanks for you input anyway, Mr. Coward.
-matthew
Re:Have you ever tried to deploy an AJAX applicati (Score:2, Informative)
We actually stuck with only commercial vendors for the AJAX apps we tried. We even worked with one of them to try to improve the performance of their Webmail product, with no avail. Read my original post for more details.
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.
Just because someone's young doesn't mean that they're stupid.
I didn't say he was stupid. I suggested he was inexperienced. And when it comes to deploying web applications to be used in a business environment by several thousand users at a time on a near-constant basis, experience is key.
Until one has actually had to deal with the performance issues of such environments, one cannot have a real appreciation of the difficulties that will be faced. And yes, that may mean finding that the technologies that make you feel all warm and fuzzy inside (AJAX, for instance) just don't cut it. When faced with empirical evidence that such technologies as AJAX just don't cut it, the best thing to do is to admit that they can't be used. Arguing against real-world experience and results does nothing to change the fact that the performance and development limitations of AJAX are problematic for many users.
In the end, Mr. Anonymous, you should be giving helpful remarks to the rest of us as to where we shouldn't be going for our apps.
I am. I'm telling you to avoid AJAX at all costs. My original post explained the problems we encountered with a number of commercial AJAX applications of various sorts. I even broke it up into four categories of problems for you. Go back and read it.
Re:FUD (Score:2, Informative)
For example, let's say you have a page where a user has some sort of an inbox from which the user can delete things, like system notifications. Next to each item, you have a delete link. Clicking on the link deletes the item, meaning javascript deletes the node from the DOM, and an AJAX call gets the thing deleted from the DB. Good use of AJAX. In fact, in an AJAX-less solution, ths user 1) has to wait for the whole page to reload, and 2) if the user presses the back button, depending on browser settings, the deleted events will seem to reappear. That could be confusing. This is one very simple example of where AJAX is great.
Consider another example. A shared calendar web application, that builds a table server side, gets all the data, runs security checks on each event to see what the current user can do to each event, and then presents the data. Building the table server-side, then pumping out tons and tons of HTML code will not only tax your web server, but also generate unnecessary network traffic. You could pretty easily refactor this application to build the table client side, and then send the data to the client via a JSON object. Now, the server page that builds the JSON object is built to check the user's cookie or whatever you use for authentication and it only sends the data that the user can see. The client takes this data and build the content client side. This is the network equivalent of purchasing a disassembled computer desk and taking it home to assemble it rather than purchasing the floor model and trying to cram it into your Mazda Miata.
I give these two examples because they are real life solutions I developed at work. Both are absolutely secure, and both save the user wait time. Also, these reduce the network and server load. What's not to like?
Of course, if you design a website whose navigation controls use AJAX, or some other weird use of AJAX you will get interesting results, and by interesting I mean bad. No offense, but I think you are saying that AJAX is a bad technology perhaps because you just don't know enough about it.
Both solutions are on an intranet, else I would gladly provide links. On the internet, would I use AJAX? Absolutely! I would, of course, use just a bit more caution...no, not because of security (I know how to make secure AJAX code) but because of browser compatibility. On the intranet, I use web standards and therefore all modern browser will work great. The nice thing is, though, you aren't going to have some weirdo using Netscape 3 or something like that. On the web, would I pander, er, I mean cater to this type of user? Depends on how much I needed them as a client.
If you want to learn more about AJAX and effective javascript constructs like JSON, check out these links: http://www.sergiopereira.com/articles/advjs.html [sergiopereira.com] and http://www.sergiopereira.com/articles/prototype.j
Re:Have you ever tried to deploy an AJAX applicati (Score:3, Informative)
The Post-and-Redirect design pattern (or the use of unique once-only form ids) solves this problem in almost all cases. Only badly written web apps still suffer from it.
The rest of your points are good, though.