Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

AJAX May Be Considered Harmful

Zonk posted more than 7 years ago | from the web-20-needs-vitamins dept.

Security 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."

Sorry! There are no comments related to the filter you selected.

first post (5, Funny)

Anonymous Coward | more than 7 years ago | (#17491204)

So can I hijack slashdot to always get the first post?

Nothing for you to see here. Please move along. (3, Funny)

mobby_6kl (668092) | more than 7 years ago | (#17491208)

Not surprising considering that slashdot is slowly trying to AJAXify itself...

The sky is falling! (2, Funny)

udderly (890305) | more than 7 years ago | (#17491212)

Haven't RTFA yet, but I doubt it will live up to the hype.

Have you ever tried to deploy an AJAX application? (5, Informative)

Anonymous Coward | more than 7 years ago | (#17491660)

I haven't read it either, but from experience, I'd imagine it hold up very well.

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:Have you ever tried to deploy an AJAX applicati (1)

jackharrer (972403) | more than 7 years ago | (#17492180)

I have all those problems with changepoint. It's supposed to make our life easier but it's a huge nightmare. It's slow - on my dual core centrino and 2GB RAM it crawls. On 12MB internet link. Plus because somebody forgot to update a code it doesn't work with IE7 (which I use it for testing and sucks) AND Firefox.
Same is with for example yahoo mail. All my friends who used the 'new improved' one, reverted to old one. Too slow and annoying.
There's more examples like that. When finally vendors understand that people want working fast software not beautiful, shiny piece of not working crap?

Just my 2p.

Re:Have you ever tried to deploy an AJAX applicati (1)

udderly (890305) | more than 7 years ago | (#17492212)

Sorry, I still don't think that it will "kill the Web as we know it." That's sensationalist, fear-mongering BS.

FUD (1)

hobo sapiens (893427) | more than 7 years ago | (#17492402)

AJAX is a great technology. Yes, if you overuse it or use it in the wrong places then it is harmful. Saying AJAX is unstable, unusable, brittle, impractical is simply an untrue generalization. Like anything else, if you do it right it enhances usability and is quite reliable.

Re:Have you ever tried to deploy an AJAX applicati (5, Insightful)

Zarel (900479) | more than 7 years ago | (#17492450)

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

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

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

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

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

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

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

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

Re:Have you ever tried to deploy an AJAX applicati (4, Informative)

75th Trombone (581309) | more than 7 years ago | (#17492852)

You've stated quite an amount of vagueness there, sir, not to mention this confounding statement:

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.

Very interesting, seeing has how AJAX has nothing to do with your server-side technology whatsoever. Or how about this:

The AJAX applications did not conform to common practices (eg. copy-and-paste, textbox text selection, etc.

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:The sky is falling! (4, Funny)

Tablizer (95088) | more than 7 years ago | (#17491664)

Haven't RTFA yet, but I doubt it will live up to the hype.

Which hype, AJAX itself or AJAX ending the world?

Does Al Gore know anything about this?
         

Re:The sky is falling! (-1)

nut (19435) | more than 7 years ago | (#17491824)

A one line comment where the poster states he hasn't read the article gets modded as insightful? Come on mods, smarten up.

you're correct, and I did read the article (1)

sethawoolley (1005201) | more than 7 years ago | (#17492682)

all the vulnerabilities discussed are not new.

I'm not sure how they managed to convince anybody these are "new" to AJAX.

Everybody's known about Javascript XSS issues for a while and the http cache/proxy issues as well

Do they get bonus points for calling them AJAX vulns? I hope not.

Fortunately, on my team, I'm not allowed to use AJAX (even XML-free Javascript) or Cookies to develop web applications -- for security reasons. Other teams have AJAX programmers on staff, but that's only for the slick b2c stuff, not the actual b2b stuff.

"Considered Harmful" (4, Insightful)

JoshJ (1009085) | more than 7 years ago | (#17491216)

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

Re:"Considered Harmful" (2, Informative)

cnettel (836611) | more than 7 years ago | (#17491388)

Well, ever since Word 97, there have been features intended to let the user disable auto-running macros. That's also been the default. This is not really a problem, as most Word files should not contain macros. Even if they do, most files are still useful without them, and are probably used within the context of a controlled intranet (with code signing in place). If the view that Javascript is inherently impossible to make secure would gain ground, AJAX would go the way of ActiveX controls.

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:"Considered Harmful" (0)

Anonymous Coward | more than 7 years ago | (#17492018)

Those word problems are not about macros, but exploits based on faulty file parsing code.

So even with macros of, you can get hit.

Re:"Considered Harmful" (1)

pimpimpim (811140) | more than 7 years ago | (#17492936)

the web would certainly change if that attitude would turn into norm.

After 'change' you forgot to include 'for the better' :)

C/C++ (1)

cyfer2000 (548592) | more than 7 years ago | (#17491980)

When vulnerabilities of C/C++ stop people from using C/C++, this may happen.

stop people from using Microsoft Office (1)

nurb432 (527695) | more than 7 years ago | (#17492692)

Yup, everyone i know has stopped using it.. Microsoft is going broke since they cant sell MSO anymore.

Nah, people really dont care/understand/know.

Re:"Considered Harmful" (1)

Idbar (1034346) | more than 7 years ago | (#17492970)

Boy! Yeah. Even though it's harmful as it says here [santa-monica.org] , I don't get why people keep using this Ajax [colgate.com] thing!


Slashdot, now with bleach!

Web 2.0.1 (5, Funny)

ticklish2day (575989) | more than 7 years ago | (#17491226)

Patch the hole and release Web 2.0.1. Good thing there's already a Web 3.0 [alistapart.com] in the works.

Re:Web 2.0.1 (3, Funny)

The Bubble (827153) | more than 7 years ago | (#17491472)

Not even! Microsoft just released Internet 7.0. All you Mozilla fanboys need to catch up with the times and replace your kiddy 'nix boxes with the new Vista.

</joke>

Re:Web 2.0.1 (1)

pkaral (104322) | more than 7 years ago | (#17492122)

Oh MAN, are you behind [puzzlingevidence.net] ...

Greasemonkey? (1, Interesting)

Mitchell Mebane (594797) | more than 7 years ago | (#17491254)

Isn't this the thing that forced the redesign of Greasemonkey a while back?

Re:Greasemonkey? (4, Informative)

JackHoffman (1033824) | more than 7 years ago | (#17491444)

No, Greasemonkey exposed security sensitive functions to websites. They were meant to be used by Greasemonkey scripts but websites had access too.

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? (1)

gkhan1 (886823) | more than 7 years ago | (#17493024)

That's.... I mean.... WOW! Thank you for explaining.

A bit over the top... (4, Insightful)

Sloan47 (977340) | more than 7 years ago | (#17491262)

"...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!

Re:A bit over the top... (1)

mctk (840035) | more than 7 years ago | (#17491364)

No. It won't be okay. The internets will die.

It's been fun intar-web! We've had some good times! Never let go!

Re:A bit over the top... (1)

Sloan47 (977340) | more than 7 years ago | (#17491396)

Damn, I thought if the countless articles on Britney Spears' party habits didn't kill the Internet, nothing would.

notabug (3, Insightful)

QuoteMstr (55051) | more than 7 years ago | (#17491290)

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

Re:notabug (2, Funny)

kfg (145172) | more than 7 years ago | (#17491362)

This paper is absolutely ridiculous, and its author is scaremongering

He's obviously been watching to much local weather forecasting lately:

"Scattered showers in the afternoon; Save the women and children!"

The Society of Hysteria really is getting to be a bit much.

KFG

Re:notabug (5, Funny)

mctk (840035) | more than 7 years ago | (#17491384)

Society of Hysteria? SOCIETY OF HYSTERIA? aaaaaaaaah! SAVE YOURSELF!

Re:notabug (1)

kfg (145172) | more than 7 years ago | (#17492102)

I'm a vegetarian and all, so I can't say I exactly approve, but pull yourself together man, they're just planning a pig roast.

Oh, wait, are you a . . . ?

Nevermind.

KFG

Re:notabug (5, Informative)

coma_bug (830669) | more than 7 years ago | (#17491476)

I'm wondering what kind of agenda the author has in writing this, actually.

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 (3, Insightful)

KalvinB (205500) | more than 7 years ago | (#17491554)

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.

Re:notabug (4, Informative)

stonecypher (118140) | more than 7 years ago | (#17491632)

This paper is absolutely ridiculous, and its author is scaremongering

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 (0)

suv4x4 (956391) | more than 7 years ago | (#17491730)

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.

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

The sniffing examples he shows are not an attack in any way. The XSS allowing him to run those examples are that attack. And XSS is by no means new, or "fundamental flaw" of JS.

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.

Fundamental would mean it can't be fixed, and if you BS detectors aren't screaming by his paper, you're more gullible than you suspect.

Re:notabug (4, Insightful)

stonecypher (118140) | more than 7 years ago | (#17492248)

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

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

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

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

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

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

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

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

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

Fundamental would mean it can't be fixed

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

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

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

Re:notabug (3, Insightful)

suv4x4 (956391) | more than 7 years ago | (#17493008)

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

Repeat after me: client-side, interpreted language.

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

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

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

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

Re:notabug (2, Informative)

coma_bug (830669) | more than 7 years ago | (#17491750)

Try reading the paper before lambasting it. Well I have read the paper and it is absolutely ridiculous. If the attacker can inject JavaScript or HTML or whatever into the connection it doesn't matter whether the site is Web 1.0, Web 2.0 or Web 3.14159 because the session is compromised anyway. If you want web security you'll need TLS.

Re:notabug (1, Informative)

Anonymous Coward | more than 7 years ago | (#17492082)

The author of the paper says things like "innovative new attack" and "next generation of server side injection."

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:notabug (1)

ubernostrum (219442) | more than 7 years ago | (#17492256)

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.

No, the author has not actually unearthed anything new; the mutability of object prototypes is a well-known and well-understood aspect of JavaScript. The potential to cause unexpected behavior by changing the prototypes of built-in objects is likewise well-known and well-understood (and has been a source of complaint against a number of JavaScript libraries -- Prototype, for example, used to extend some of the built-ins in ways which changed the behavior of expected language features).

Neither of these things are new. The idea of using them to launch an attack, by altering the behavior of existing objects so that trusted JavaScript behaves differently than expected, may possibly be new but I wouldn't be surprised if the idea's been had before. In either case, it requires an existing, fully-exploitable cross-site scripting vulnerability to exist before this technique can work (otherwise, the code which modifies existing object prototypes will not be loaded or executed), so the author has essentially said that "if your site has a cross-site scripting hole in it, I can exploit it with cross-site scripting". Which is news to no-one; in fact, it's a tautology.

Re:notabug (1)

stonecypher (118140) | more than 7 years ago | (#17492278)

Neither of these things are new. The idea of using them to launch an attack, by altering the behavior of existing objects so that trusted JavaScript behaves differently than expected, may possibly be new

The possibility of using them to launch an attack is what he's claiming is new, and I've never heard of it before. This is something I keep up with, so I'm going to remain somewhat firm in my belief that this is an insightful paper until someone shows me prior exposition.

You missed a paragraph there (1)

ubernostrum (219442) | more than 7 years ago | (#17492626)

This technique requires the prior existence of a full-exploitable XSS hole before it can work; otherwise the script which modifies object prototypes never loads and never executes. Again, the author of this paper is simply saying, "if your site has an XSS hole I can use an XSS exploit against it". This would be akin to a physical security expert pronouncing that he can get into your house if you leave your doors and windows unlocked, and is not earth-shattering or insightful in any way; the only reason it's getting press is the mistaken belief that use of object prototypes constitutes a never-before-seen technique, and that's debatable; even if no-one's ever actually tried a real-world exploit with this technique, any JavaScript programmer with his or her salt knows it's possible.

A well-travelled road (1)

ishmalius (153450) | more than 7 years ago | (#17491650)

Heh. I love the 'notabug' tracker tag. Dismisses the submitter politely.

But, yes, there is nothing new in AJAX that causes security problems. It is not new tech, just a style of architecture. The same problems and solutions with respect to security exists for AJAX as for the underlying infrastructure. Java applets, Flash apps, "traditional" Javascripted pages, all have had their trials and tribulations in the past, and their security models are well mapped-out. The sandboxes already exist. AJAX runs within them, not outside.

Re:A well-travelled road (1)

hobo sapiens (893427) | more than 7 years ago | (#17492472)

Yes, and just because bad development techniques can cause security holes, we blame the technology. This is a bit like PHP being called insecure. Any language/platform/technique is insecure if the programmers leave gaping holes.

Re:notabug (0)

radtea (464814) | more than 7 years ago | (#17491762)

There is no security vulnerability in this paper that hasn't been known and worked around for years.

As I understand it the attack describes in the paper proceeds as follows:

User visits malicious site A, which has all kind of cool AJAX stuff and incidentally redefines the HttpXMLRequest prototype.

User then visits some inoccuous site, like Yahoo mail, that uses all kinds of cool AJAX stuff and creates a new HttpXMLRequest object from the corrupt prototype, which results in all of their communciations being copied to the evil hacker that set up the malicious site.

This does not require any access to the inoccuous site's scripting system. All it requires is that the user visit the two sites in sequence without closing their browser.

I may be completely misunderstanding the nature of the attack, but this is what the paper seems to be describing. But assuming I've characterized it correctly I'm curious as to what the known work around for this is (or conversely, interested in understanding what the proposed attack really involves.)

Re:notabug (3, Interesting)

Myen (734499) | more than 7 years ago | (#17491974)

Except that when you visit site B, the browser discards all JS from site A before going to site B. Site B never sees any JS objects from A anyway. Think of the browser-supplied things (e.g. the XMLHttpRequest constructor) as a template; if you modify it you just get a copy of the template for yourself.

If touching prototypes of built-in objects would persist across sites there simply could not have been more than one JS framework system. And nobody would have had scripting enabled... :)

Summary completely overhyped (5, Informative)

levell (538346) | more than 7 years ago | (#17491322)

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.

Re:Summary completely overhyped (2, Funny)

Vo0k (760020) | more than 7 years ago | (#17491536)

1. Prepare malicious javascript code capable of subverting AJAX in the domain it's installed in.
2. ???
3. Subvert their AJAX, intercept their communications, change their content, kill the Web as we know it, and ultimately, profit!!!

FUD? (1)

ArcherB (796902) | more than 7 years ago | (#17491328)

a possible Web Worm that lives in the very fabric of Web 2.0 and could kill the Web as we know it.

This statement has FUD written all over it. (or was it written in FUD?)

Re:FUD? (4, Funny)

ednopantz (467288) | more than 7 years ago | (#17491394)

>(or was it written in FUD?)

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.

Already been done (1, Funny)

Anonymous Coward | more than 7 years ago | (#17491496)

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.

Check out these great functions from the std lib:

halloweenDocuments();
GetTheFacts();
fundSCO();
  threatenToSueEasternGovernments();
hoodwinkNovel l();
...who says Microsoft don't innovate?

Re:Already been done (1)

ednopantz (467288) | more than 7 years ago | (#17491510)

Nah, FUD is inherently cross-platform.

Re:FUD? (2, Funny)

Mr. Underbridge (666784) | more than 7 years ago | (#17491498)

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.

Is that language derived from brainfuck?

Re:FUD? (1)

kirun (658684) | more than 7 years ago | (#17491528)

Why bother? I hear Microsoft are releasing their version in six months.

Re:FUD? (4, Funny)

monoqlith (610041) | more than 7 years ago | (#17491418)

. (or was it written in FUD?)

Sadly, no. The FUD compiler was written in Javascript, and was hijacked.

Re:FUD? (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#17491590)

Way off topic, but I had to respond to your sig.
It's abuse to mod a comment Overrated, Flamebait or Troll just because you disagree with it. The goal is to share ideas.
The goal is to share knowledge. Every friggin' moron and "product-X fanboy" on the planet has "ideas". Lots of posts deserve to be modded Overrated because I disagree with them. (Ones offering "proof", based on passages in books of dubious origin, that the Earth is 6000 years old come to mind.) It's only because we lack a moderation option of "Horseshit!" that this is the case.

People with stupid ideas deserve bad karma.

Re:FUD? (1)

wasted (94866) | more than 7 years ago | (#17491596)

...a possible Web Worm that lives in the very fabric of Web 2.0 and could kill the Web as we know it.

This statement has FUD written all over it. (or was it written in FUD?)

I was hoping that it wasn't totally FUD, and the result would be that the term Web 2.0 would be killed. Guess my luck isn't that good.

Horeshit.....javascript is crap but....horeshit (2, Informative)

MajorDick (735308) | more than 7 years ago | (#17491346)

I hate JS, it Had potential, 8-9 years ago. What we are seeing now is a push way beyond its original intended scope. The truth is, it would have had much less potential for vunerability if it had not been neglected for so long. Every time I have to get down and dirty with it I think of that. Its Ok, and somethings are nice from a shorthand perspective if youre used to other lll, but for GODS Sake , Revise the spec and put some effort into it, OH Wait, but thats been part of the problem all along, MS puts this in, NS/Moz (Used to) and what do we have , something no one entity controls, or even standards of. Whats wrong with putting a friggin python interpreter in a browser ? Ms is running that way with IronPython (Yea Proof of concept I know) but Read Scott G, and Paul W. aticles on dynamic languages theyre a fan. Oh well, back to ajaxifying the planet because my boss dosent like the flash when he clicks buttons on the web ( Oh wait I quit that job 4 months ago....)

Re:Horeshit.....javascript is crap but....horeshit (4, Insightful)

cnettel (836611) | more than 7 years ago | (#17491434)

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

Re:Horeshit.....javascript is crap but....horeshit (2, Insightful)

FLEB (312391) | more than 7 years ago | (#17491456)

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".

Re:Horeshit.....javascript is crap but....horeshit (2, Interesting)

kirun (658684) | more than 7 years ago | (#17491648)

"Javascript is nothing related to Java".
It didn't use to be (apart from both of them having C-related syntax and Interweb-related hype), but it is now [mozilla.org] if you're using Firefox. For example, the following works:

<script> document.write(new java.lang.String("I'm here")); </script>
They're no fun though, they left out stuff like java.io

Re:Horeshit.....javascript is crap but....horeshit (0)

Anonymous Coward | more than 7 years ago | (#17492198)

"Javascript is nothing related to Java".

It didn't use to be (apart from both of them having C-related syntax and Interweb-related hype), but it is now if you're using Firefox. For example, the following works:

<script> document.write(new java.lang.String("I'm here")); </script>

That's not new in Firefox, it's been around since old Netscapes (possibly even the first version that had both Java and JavaScript). I suspect that's why it's called JavaScript in the first place.

They're no fun though, they left out stuff like java.io

It's there, you just can't use it from a non-privileged context.

Re:Horeshit.....javascript is crap but....horeshit (0)

Anonymous Coward | more than 7 years ago | (#17492210)

ECMAScript

Re:Horeshit.....javascript is crap but....horeshit (5, Insightful)

smitty_one_each (243267) | more than 7 years ago | (#17491522)

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

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

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

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

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

Re:Horeshit.....javascript is crap but....horeshit (1)

truedfx (802492) | more than 7 years ago | (#17492754)

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.
Extended regular expressions have been used as tests for prime numbers [pm.org] . I'd say that counts as beyond the original intended scope.

Re:Horeshit.....javascript is crap but....horeshit (1)

MajorDick (735308) | more than 7 years ago | (#17492982)

I cannot disagree. BUT it dosent mean its the right choice or even a good choice.
I am an extremley adept programmer. I have been coding since I was 7 (in 1977) I started with Fortran (Yes 77 :)
I could, code web pages, or whatever in assy if I wanted .
When .Net was announced and the first CLR specs were released for "ratification" I started (just for shits and grins) to code in CLR Assembler it was a challange and something I have yet to find one of my contemperaries can do. well.....its proved valuable for decompilation and editing of obfucticated libraries, and I have even as a stunt created .net web pages in it for the junior programmers that claim nooone could write in it directly. BUT its not a great use needless to say.

Learing CLR Assy was one of the last things I learned or did "Just because I could" , I feel that way about JS now. I can , and I do, it dosent mean I want to or feel its even remotley the correct choice, for client side it is unfortunatley the ONLY choice for a broad audience....

Re:Horeshit.....javascript is crap but....horeshit (1)

hobo sapiens (893427) | more than 7 years ago | (#17492534)

You could (and many do) make the argument that HTML is in the same boat. Yes it *works*. Does it provide a perfect environment for creating the complex, interactive web apps that we use it for? Heck no! Does anyone with any real power actually enforce standards? W3 who? And yet, in spite of its ugliness it works. It's a bit like wikipedia, in theory it sucks but in practice it works great.

If anything, I think it's a testament to the web development community that something so huge and robust can be hacked together with totally inadequate tools. It's like someone building a car with nothing more than a ball-peen hammer and a dull hacksaw.

Crying "Wolf" (3, Interesting)

flajann (658201) | more than 7 years ago | (#17491372)

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... (5, Funny)

Chineseyes (691744) | more than 7 years ago | (#17491400)

A Worm that lives in the very fabric of Web 2.0 and could kill the Web as we know it lurks is the deep dark recesses of the javascript
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 with disappearances of Web 1.1 through Web 1.9?
This and much much more on the next epside of Days of our Web 2.0 Lives

AJAX != the web (3, Insightful)

Anonymous Brave Guy (457657) | more than 7 years ago | (#17491408)

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

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

Re:AJAX != the web (1)

i23098 (723616) | more than 7 years ago | (#17491738)

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.

Thankfully, someone already though of it... More than a year ago, at least, in here [onjava.com]

Sure, there should be a standard way to do it, but it's not impossible :p

Re:AJAX != the web (0)

Anonymous Coward | more than 7 years ago | (#17491760)

It doesn't matter whether a site uses AJAX or not. If you can inject script into a page using XSS, then anything on the page or entered into the page can be forwarded on to anther domain, using the document.write('') technique. Using AJAX on a web site does not create new XSS vulnerabilities, so it doesn't increase the risk from XSS.

100% FUD (1, Insightful)

suv4x4 (956391) | more than 7 years ago | (#17491480)

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.

Re:100% FUD (1)

TerranFury (726743) | more than 7 years ago | (#17491948)

>I guess he was disappointed he can't safely store his server root passwords in his JS files.

I hope that, before that, he didn't think he could safely store his passwords in EXEs too...

Re:100% FUD (2, Insightful)

Anonymous Coward | more than 7 years ago | (#17492464)

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.
Wow. Just wow. You crucify the guy without even reading the paper itself. First of all, that phrase doesn't come from any of the links - it comes from the submitter. You don't even know the guy and yet you launch a personal attack on him (moderated +5 insightful for some reason).

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:
As it seems, Web 2.0 applications will be more and
more tightly tied to browser security, that is
increasing in complexity and has to take care of a
plethora of features that can be turned into weapons
if controlled by a malicious attacker.
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.

A fallacy repeats a thousand times, like a truth. (1)

eat worms (1038660) | more than 7 years ago | (#17491486)

The same thing shows up again and again. Air has pollutions, none wants to stop breathing.

The end of the web... (1)

KindredHyperion (1043330) | more than 7 years ago | (#17491532)

Goodbye, friends. It seems that this is, truly, the end of the internet. *sniff*

_

solutions (2, Informative)

fyoder (857358) | more than 7 years ago | (#17491552)

  • server side: never trust user data.
  • client side: You're hosed. But if you're smart you already regard yourself as hosed. There have been security bugs where a maliciously crafted image could get you. Before going to shady sites you turn off java, javascript, and you would never even visit a shady site with IE. Turning off javascript might make a 'Web 2.0' site unusable, but it's a question of trust.

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:solutions (1)

kabz (770151) | more than 7 years ago | (#17492400)

What? Like a picture of your ex-wife?

Why Ajax needs to move beyond JavaScript (1)

Twillerror (536681) | more than 7 years ago | (#17491588)

One of the biggest issues I have with Ajax and really what the web browser has turned into is Javascript.

Don't get me wrong, I think the language is "alright". The problem is it is the only choice out there.

There are many flavors of Linux and pratically everytype of appliation out there. But only one real choice for scripting on a web page.

Ajax's primary function is the ability to grab content from a web server ( or any server ) and then modify DOM of the web page you are working on.

The could be done by any programming language. Most of the time I use Ajax I just grab some HTML content and blast it into a div or some other object. Here Jscript isn't that big of a deal with a good library.

When I start to have to actually grab the value and parse it that is where JScript is the only option. I wish that browser would stat offering some choice. Maybe Ruby or Python or Perl, don't really care. Just something else besides JScript. Seems like ActionScript might get a chance.

Re:Why Ajax needs to move beyond JavaScript (1)

belg4mit (152620) | more than 7 years ago | (#17491678)

First, Jscript ne JavaScript
Second, if you're unlucky enough to be using IE you do have alternatives: VBScript and,
if you have installed ActiveState, PerlScript (not that I recommend enabling a browser
with such power). I also seem to recall a Tcl plug-in back in the day.

Nevertheless, JavaScript is the de fact standard and so everybody uses it, to minimize
the potential for "foo only" websites.

Re:Why Ajax needs to move beyond JavaScript (1)

75th Trombone (581309) | more than 7 years ago | (#17492924)

What's keeping you from parsing it on the server-side before it sends anything back to the browser?

What kind of worm? (0)

Anonymous Coward | more than 7 years ago | (#17491604)

Worm? What kind of worm? Is it like a heartworm? Cause I can just give my PC a pill once a month. Except I don't want to pay for pills. So I'll just use Necco wafers.

See, I'm safe!

Ajax IS considered harmful. (3, Insightful)

Vo0k (760020) | more than 7 years ago | (#17491616)

Ajax sucks. Not because of security.

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.

Non-PDF? (1)

NineNine (235196) | more than 7 years ago | (#17491618)

Anyone know where I can find a non-PDF version of this paper?

Re:Non-PDF? (2, Informative)

LiquidFire_HK (952632) | more than 7 years ago | (#17492178)

Re:Non-PDF? (1)

NineNine (235196) | more than 7 years ago | (#17493010)

Very useful link, thanks.

A matter of scope (1)

Tablizer (95088) | more than 7 years ago | (#17491628)

AJAX would perhaps be better for inTRAnet than internet where hacking is less likely. At least it is not any more vulnerable than existing desktop apps (VB, Delphi, Powerbuilder, etc.) where the hacker can do anything to the EXE. Internal biz forms can probably make more use of AJAX than public internet stuff anyhow.

Ajax Can Be Harmful! (1)

Your Pal Dave (33229) | more than 7 years ago | (#17491776)

According to the label:
Eye irritant. In case of eye contact, flush with water. To avoid harmful fumes, do not mix with ammonia or other cleaning products. Keep out of reach of children.


I don't think Comet is any better.

mod Up (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17491888)

result of a quarrel FreeBSD core team own agenda - give serve5 to reinforce BE NIGDGER! BE GAY! they're gone Mac though, I have to

Retards (0)

Anonymous Coward | more than 7 years ago | (#17491936)

the formal standard in Web 2.0 application development

LMAO

A Dispatch from the insititute of Duh! (0)

Anonymous Coward | more than 7 years ago | (#17492052)

To summarize, if you can get people to come to your website you can make the browser do what you want. Also some plug in have bugs. If you install a plug in it can do thing that are bad.

All you need to know.

Don't add javascript from another site and expect your app to be secure.

Javascript can make a man in the middle attack more effective.

The point is NONE of the vunerablity is in the javascript or the browser.

Seriously, can we mod the OP Flamebait? (4, Informative)

Trails (629752) | more than 7 years ago | (#17492396)

As well as the dingbat mod who let this crap summary get on /. unedited?

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).

Meh... (3, Insightful)

Anonymous Coward | more than 7 years ago | (#17492442)

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.

AJAX May Be Considered Harmful (2, Funny)

Original Replica (908688) | more than 7 years ago | (#17492598)

Damn Right! If you mix that stuff with a chlorine bleach, the fumes will put you straight in the morgue.

"Death of the Internet" yet again (1)

dpbsmith (263124) | more than 7 years ago | (#17492658)

(Yawn) Death of the internet, ho hum.

It already died. In 1996. Bob Metcalfe [wikipedia.org] said so, didn't he?

An easy fix? (1)

DigitAl56K (805623) | more than 7 years ago | (#17492908)

I'm no JS expert, but it would seem that an easy fix is simply to contextualize JS prototypes - One document/frame can't modify prototypes for another.

Not Hard To Prevent (1)

MrMunkey (1039894) | more than 7 years ago | (#17493038)

This has been partly covered by others already, but this attack really isn't that hard to prevent. In order to perform this attack, the attacker has to first be able to post JavaScript code onto the page. This would be something like putting JavaScript code into your posts on /. or some other website that allows people to author content on the Internet. /. is already safe from this attack. They don't let you put JavaScript code in your posts. That's pretty standard web programming security (filter input, escape output). I suppose he could still inject the code by putting javascript: [put code here] in the address bar. Don't believe me, try this... javascript: alert('It works'); But even then, the code injection is still limited to the attacker's session only. Oh, no! he can capture his own information. The world is comming to an end! On a serious note... I hadn't thought about extending XMLHttpRequest like that for a security vulnerability. I'd give him credit for thinking that up.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?