AJAX May Be Considered Harmful
Posted by
Zonk
on Sat Jan 06, 2007 04:19 PM
from the web-20-needs-vitamins dept.
from the web-20-needs-vitamins dept.
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."
Related Stories
[+]
Experts Say Ajax Not Inherently Insecure 82 comments
An anonymous reader writes "Jeremiah Grossman (CTO of WhiteHat Security) has published Myth-Busting - an article dismissing the hyped-up claims that AJAX is insecure. He says: 'The hype surrounding AJAX and security risks is hard to miss. Supposedly, this hot new technology responsible for compelling web-based applications like Gmail and Google Maps harbors a dark secret that opens the door to malicious hackers. Not exactly true ... Word on the cyber-street is that AJAX is the harbinger of larger attack surfaces, increased complexity, fake requests, denial of service, deadly cross-site scripting (XSS) , reliance on client-side security, and more. In reality, these issues existed well before AJAX. And, the recommended security best practices remain unchanged.'"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
first post (Score:5, Funny)
re: first post (Score:4, Interesting)
(http://jimbojw.com/wiki/index.php?title=blog)
Further, the slashdot summary suggests that Prototyping is a design flaw in JavaScript/ECMAScript. This wrong for two reasons:
- The article doesn't mention this.
- Prototyping is not a design flaw.
Prototyping is a very useful language feature that can be used to do all sorts of things that would otherwise be cumbersome or impossible. Ruby is a prototyped language - a feature which is responsible for much of the 'magic' of Rails.The article does outline a number of Ajax related vulnerabilities, but like most vulnerabilities, they can be mitigated or avoided entirely if paid attention to - much like the SQL injections of old.
Arguing that Prototyping or Ajax makes JavaScript unsafe is fud. These are powerful language features that (like any powerful feature) can be used for evil if an injection mechanism is available.
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".
Nothing for you to see here. Please move along. (Score:4, Funny)
The sky is falling! (Score:2, Funny)
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:FUD (Score:5, Interesting)
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: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: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:Have you ever tried to deploy an AJAX applicati (Score:5, Funny)
By enabling development to occur at all. The program that is never written has zero bugs and is therefore the perfect program.
Re:Have you ever tried to deploy an AJAX applicati (Score:4, Informative)
(http://75thtrombone.com/ | Last Journal: Tuesday August 07, @11:39PM)
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.
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:The sky is falling! (Score:4, Funny)
(http://www.geocities.com/tablizer | Last Journal: Saturday March 15 2003, @01:22PM)
Which hype, AJAX itself or AJAX ending the world?
Does Al Gore know anything about this?
"Considered Harmful" (Score:5, Insightful)
Web 2.0.1 (Score:5, Funny)
Greasemonkey? (Score:2, Interesting)
(http://whattheboat.com/ | Last Journal: Monday January 03 2005, @09:14PM)
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: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.
A bit over the top... (Score:4, Insightful)
notabug (Score:3, Insightful)
Re:notabug (Score:5, Funny)
(http://koutouki.org/)
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.
Circumventing the XSS protection of AJAX (Score:4, Insightful)
(http://www.icarusindie.com/)
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.
Re:notabug (Score:5, Informative)
(http://sc.tri-bit.com/ | Last Journal: Sunday July 08, @02:36AM)
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.
Re:notabug (Score:5, Insightful)
(http://sc.tri-bit.com/ | Last Journal: Sunday July 08, @02:36AM)
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 proba
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:notabug (Score:4, Insightful)
(http://trolltalk.com/ | Last Journal: Saturday November 03, @08:45PM)
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.
Summary completely overhyped (Score:5, Informative)
(http://www.coralbark.net/)
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.
FUD? (Score:2)
(Last Journal: Monday April 30 2007, @10:21PM)
This statement has FUD written all over it. (or was it written in FUD?)
Re:FUD? (Score:5, Funny)
Ok, I propose we create a new programming language called FUD. Variables will be assumed to have their most sinister values and be impossible to verify.
Re:FUD? (Score:5, Funny)
Sadly, no. The FUD compiler was written in Javascript, and was hijacked.
Horeshit.....javascript is crap but....horeshit (Score:2, Informative)
Re:Horeshit.....javascript is crap but....horeshit (Score:5, Insightful)
Re:Horeshit.....javascript is crap but....horeshit (Score:5, Insightful)
(http://www.emacswiki...iki/ChristopherSmith | Last Journal: Wednesday November 07, @07:35AM)
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.
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.
Crying "Wolf" (Score:3, Interesting)
(http://www.justblamefred.com/ | Last Journal: Tuesday October 18 2005, @11:34PM)
Do they ever learn? All of this scaremongering is numbing the uninitiated, and when there is a real threat no one will be prepared.
Well, my BS meter pings off the scale when I see alarmist claims like "shutting down the web." How many of those claims have we all seen over the past years?
I suppose it's the 21st-century equivalent of "The World is Comming to an End!"
I consider that anyone who makes such outlandish claims should be remembered, indexed, marked, and noted. When their claims fails to come true, then we can all stand around and laugh at them and grant them Idiot Awards.
On the next episode of Days of Our Web2.0 Lives... (Score:5, Funny)
Who is this masked man known as the worm?
Why does he hate Web 2.0 so much?
Will this worm try to make us revert to Web 1.0?
And does this worm have anything to do