Slashdot Mirror
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."
Javascript vulnerabilities will stop people from using AJAX just like Word vulnerabilities will stop people from using Microsoft Office.
Care about privacy? Read this!
"...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!
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.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
The problem is that any other interactivity solution has to be universally applied, and right now there's a universal solution that's adequate, more adequate than instituting a ground-up rebuild, so anything in the future is going to be tacked-on to that. I suppose the best we can hope for is incremental, inside-to-out cleanup of the language, and, like CSS and "quirks modes" do, old code that breaks is switched to a legacy mode. Still, though, I think it's going to stay JavaScript, at least for the forseeable future. There's just too much inertia.
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".
Information wants to be free.
Entertainment wants to be paid.
You just want to be cheap.
You can detect it even from the summary: "a Web Worm that lives in the very fabric of Web 2.0 and could kill the Web as we know it."
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.
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.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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.
Work Safe Porn
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.
Anagram("United States of America") == "Dine out, taste a Mac, fries"
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.
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.
Want a high quality FOSS RTS game? Try Warzone 2100!
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.
You're confusing the AJAX protocol with a complete AJAX application. I'm talking about complete applications, involving both the client-side and the server-side. After all, a protocol is pretty useless unless there are applications involved making use of that protocol.
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.
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.
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.
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.
Want a high quality FOSS RTS game? Try Warzone 2100!
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.
Maybe not
Speed is not the only criteria one uses to judge a Web application. For many people, being able to bookmark a page is very important. When it comes to sites using AJAX, such bookmarks are often not possible.
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.
It sounds like you have issues with these specific products; I don't see how you can apply this to all of AJAX.
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.
Bookmarking has been subverted way before AJAX came along. Any website generated from POST information can't really be bookmarked. That's what PERMALINK is for.
If it's no on fire, it's a hardware problem.
If it's no on fire, it's a hardware problem.
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.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
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!!!
blah blah blah
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.
while (!asleep()) sheep++
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".
i ate crayons when i was a kid and now i have two braincells and the blue ones taste nicer
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?
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.).
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. AJAX doesn't cut it for real-world deployments, kid. I know, you probably won't believe me. After all, I've only directly experienced the problems AJAX presents. I've only attempted to deploy eight AJAX applications, only to see all eight fail horribly. I can understand your frustration. But, please, try Ajax sometime in the future, after it's no longer Buzzword of the Week and you can find people who actually know how to use it properly, and you might find that it's a lot better than what you thought. I'm not talking about your experience with AJAX. Think bigger, kid. I'm talking about your lack of experience doing large-scale enterprise deployments. We're not throwing together some site for your high school that'll get 250 hits per month.
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. I've written Web sites that take advantage of Ajax that were used by a lot more than 8000 people. Believe me, I know how to use it in ways that actually save bandwidth and server processor cycles.
Want a high quality FOSS RTS game? Try Warzone 2100!