Slashdot Mirror
Web 2.0 Under Siege
Robert writes "Security researchers have found what they say is an entirely new kind of web-based
attack, and it only targets the Ajax applications so beloved of the 'Web 2.0' movement.
Fortify Software, which said it discovered the new class of vulnerability and has named it
'JavaScript hijacking', said that almost all the major Ajax toolkits have been found vulnerable. 'JavaScript
Hijacking allows an unauthorized attacker to read sensitive data from a vulnerable
application using a technique similar to the one commonly used to create mashups'"
So, how is this different than Javascript injection or Cross-site Scripting?
Sadly, this is likely to do very little to stop the use of the word 'mashups'.
How is this different from cross-site scripting?
"In an example attack, a victim who has already authenticated themselves to an Ajax application, and has the login cookie in their browser, is persuaded to visit the attacker's web site. This web site contains JavaScript code that makes calls to the Ajax app. Data received from the app is sent to the attacker."
ClutterMe.com - easiest site creation on the Net. Just click and type.
How is this different than Cross Site Response Forgery?
o rgery
http://en.wikipedia.org/wiki/Cross-site_request_f
Upgrade to Web 3.0, quick!
Libertarian Leaning Political Discussion Forum.
...every last punkwad that attacks someone's computer systems for fun or profit.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
This has been around for (web) ages. As stated in the summary, it's used all over the place to create mashups because it's one of the only ways around the security requirement that XmlHttpRequest can only talk to the originating server.
no text I said.
My turnips listen for the soft cry of your love
Slashdot Burying Stories About Slashdot Media Owned
that we can sue Morfik? /sarcasm
Support NYCountryLawyer RIAA vs People
"In an example attack, a victim who has already authenticated themselves to an Ajax application, and has the login cookie in their browser, is persuaded to visit the attacker's web site. This web site contains JavaScript code that makes calls to the Ajax app. Data received from the app is sent to the attacker."
So essentially it means that the attacker can use the authentication cookie of the user to authenticate them again, and then run javascript with that authentication. But why are AJAX apps storing authentication in cookies? If you need to store authentication (User session id's etc), store them in a variable within the javascript. That'll stay there until a page refresh clears variable status, and how many page refreshes occur with AJAX?
AJAX apps do not need to (and should not!) store user authentication in cookies. Cookies are useful for keeping a continual session open between pages. AJAX needs no continual session. If they don't use cookies, then other sites cannot use that authentication.
Where's the problem? (What am i missing?)
PimTerry
"Social Software is stuff that gets spammed."
The obvious implication of Shirky's Law is that Web 2.0 services are an attractive nuisance and give spammers and other griefers an incentive to game the system. Any new web service has to account for this and build in extremely high levels of security. Obviously nobody is doing this.
This is a vulnerability that appears only when passing Javascript between client and server. An attacker has to get a potential-victim who is logged-in to a site, that uses the JSON format to exchange data using AJAX, to visit a page they've setup. Then the attacker can intercept the data as it travels between client and server, a man in the middle attack. From the article:
So it's a known method of attack, but because it's aimed at web sites using AJAX it has to be labelled 'Web 2.0'. Ugh.
I'm going to transform myself into a mighty hawk. Either that or I'll just go and work at Dixons, haven't decided yet.
It actually could be pretty nasty. I think the only solution is for you to pass authenticated tokens through the url or input parameters (not through cookies).
It might be a good time to use the firefox NoScript plugin if you're not using it already. Only allow javascript on sites you trust.
-- these are only opinions and they might not be mine.
I went to an Ajax conference last fall and I'm pretty sure that presenters mentioned this vulnerability in JSON.
All AJAX applications transfer data between the webpage in the client's browser and the server. If the data is in XML, the webpage and the XML have to come from the same server. If it's JSON (JavaScript Object Notation), then they do not have to come from the same server. So, if you are sending data that depends on some kind of authentication - don't use JSON.
The JSON vulnerability comes from having your session open too long. Someone navigates to a bad site and it access the active session on the target site. Shorter session timeouts help with this. You can also do some authentication in the XML request as well. And don't use JSON for data that requires authentication.
In short, if you're using AJAX for data that requires authentication, then you need to take some simple precautions.
Just serve up an animated cursor before any XML handshakes. This will stop the attackers from exploiting the AJAX piece.
Is there such a thing as an authorized attacker?
"Web 2.0" is a buzzword used by those in the media who do not have a background in and/or an understanding of technology. Discuss ....
I think the article is a bit exaggerated but if the idea that "Web 2.0" is under attack might be a good time to look at this problem. Consider that a lot of people only surf a few websites (get some news, etc) and use e-mail. Most people don't use the net for anything more.
So if I only visit about 10 websties daily and those 10 sites I'm reasonably sure are safe why would I go anywhere else if it could cause problems to my computer? I've seen and heard from a lot of people fed-up with spyware, adware and viruses. Its a waster of their time. So going to these other sites, simply because they could be infected would also be a waste of their time (assume they're interested in the content). If this blows up any more - or alternately - if the perception exists that the Internet will only get worse, its not going to help people go much past those 10 websites regularly.
Is anyone actually suprised by this? It was only a matter of time since most people are using all the frameworks out there and more than half of the AJAX sites that spawned up arent fully protected by smart coding since its a new technology.
Bryan
Actually, I'd claim "everybody" with a toe in the security world thought it was the opposite; we'd start hearing about daily/weekly Ajax security problems as a regular course of business.
(If you think various operating systems have legacy code problems; you don't know "Javascript as implemented by browsers"...)
The biggest WTF is that somebody is still using javascript. Oops. Wrong site...
(Captcha: backtotheweb1.0)
All: I encourage all of you to read the detailed report Fortify wrote on this topic. Its written for developers and explains the problem in clear technical detail. http://www.fortifysoftware.com/advisory.jsp (No registration required) Its a long document but I doubt you'll have a lot of questions after reading it. Its refreshing to see reports written like this that don't insult a developer's intelligence.
This just sounds like a fancy Cross-Site Request Forgery.
I still maintain that the collective blindness to these security issues comes from our absolute refusal to see HTTP requests as function calls. This is partly due to the silly ideology of the REST crowd.
Rephrase the situation as follows and see if this doesn't make you pee your pants: "Any site can instruct your browser to execute an arbitrary function on another site using your authentication credentials."
An application may be vulnerable if:
p ublic/JavaScript_Hijacking.pdf
- It uses cookies to store session IDs or other forms of credentials; and
- It sends data from server to browser using "JSON" notation; and
- It doesn't require POST data in each request.
A vulnerable application can be fixed by changing any of these three aspects:
- Stop using cookies, and instead supply the credentials in the request's URL or POST data.
- Don't use JSON, or munge your JSON so that it can't be run directly from within a <script> tag; for example, you could put comments around it in the server and strip them off in your client.
- Have the client send some POST data and check for it on the server (a <script> tag can't send POST data).
My preference, and the strategy that I've used in Anyterm and Decimail Webmail, is to not use cookies. To me it actually seems easier to put the session ID in the request, rather than to mess around with cookies.
The advisory, which explains it all but is a bit waffly at the start, is at http://www.fortifysoftware.com/servlet/downloads/
MySpace 2.0 is then, by extension, doomed. Watch CNN for exciting stories of the kiddie Internet wild west, where sexual predators and teenage hackers battle over rocky terrain useless to anyone with anything of import on their minds.
technical writing / development
If you delegate operations and processes to client side, sooner or later they will be finding more ways to exploit it to an extent that it would be a security risk to offer such client side stuff, making anti-virus, anti-spyware, privacy product manufacturers more agitated about it, and in the end drawing visitors away from your site due to blocks, issues, and fear.
Read radical news here
XML is now so last week. Really l33t web apps use JSON, which is yet another way to write S-expressions like those of LISP, but now in Javascript brackets.
There are several security problems with JSON. First, some web apps parse JSON notation by feeding it into JavaScript's "eval". Now that was dumb. Some JSON support code "filters" the incoming data before the EVAL, but the most popular implementation missed filtering something and left a hole. Second, there's an attack similar to the ones involving redefining XMLHttpRequest: redefining the Array constructor. (Caution, page contains proof of concept exploit.)
The real problem is JavaScript's excessive dynamism. Because you can redefine objects in one script and have that affect another script from a different source, the language is fundamentally vulnerable. It's not clear how to allow "mashups" and prevent this. The last attempt to fix this problem involved adding restrictions to XMLHttpRequest, but that only plugged some of the holes.
As a minimum, it's probably desirable to insist in the browser that, on secure pages, all Javascript and data must come from the main page of the domain. No "mashups" with secure pages.
Wrong. It's a buzzword used by the media to represent interactive web applications, whether they understand technology or not. It's useful because it's painfully simple, and non-techie people get the basic idea.
/. audience, so don't take it personally when they disregard us. And don't get upset at them for using certain words when they weren't talking to us in the first place. We may make a lot of things work, but the world doesn't revolve around ./!
Given that the article was not aimed directly at web developers, but at people interested in computing in general, it's appropriate for them to use buzzwords to convey their message.
If I'm talking with another web developer, I'll get upset if he/she uses "web 2.0" in a sentence -- when it comes to my profession, I hate the word. When dealing with non-web tech savvy people, it's a helpful tool to refer to dynamic websites of the type that may have this vulnerability.
Very few news articles are ever written for the
That is, when ANY new technique or code module is to be used in a production environment, it should not be considered ready until it has been thoroughly attacked by a person who has the kind of mind-set that will expose code vulnerabilities before a user (or set of users) finds them.
Trouble is, most IT organizations have a hard sell to get that type of person within the company -- first, because an "inside the firewall" attacker is counter-intuitive to the idea that a company should trust their employees, and second, the position seems redundant IF the programmers are up to speed on writing secure applications. Which -- catch 22 here -- they won't know until it is too late. Secondarily, inside the wire attackers are much more dangerous than outside attackers, because the inside the wire person comes to know exactly what is vulnerable, and what can be done with that knowledge.
Any thoughts?
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
Fortunately the web development community has learned so much from the ongoing ramifications of Microsoft's "features first, security later" approach in the 90's that we would never recreate such a mess. Oh wait - automatic, default execution of third party code on the client browser, INSIDE THE FIREWALL? What could possibly go wrong with that?
The arguments today also mirror what went on with Windows and Outlook in the 90's. A few wild haired prophets screaming doom and gloom but 99.9% of the IT community was/is hypnotized by the glamour of "features, features, features" and security is relegated to patching. Like building a submarine out of swiss cheese. You'll spend the rest of your life patching but if everyone does it, it's normal. A few weirdos will look up and say "why don't we just start with a less porous base material?" but they will be shouted down by the masses.
Javascript, Flash and Applets are insecure by concept. Oh, pardon me, sandboxes will take care of everything? Append an image to the DOM from your server. If that "image" is actually a program which reads the query string you can pass it any information you want. Sandbox jumped. Not a bug, a feature.
It's not enough to patch websites. It only takes one popular compromised site to infect thousands or even millions of users. Do I trust every site on the internet to be 100% invulnerable 24/7? Not really. Not even the sites I work on.
Most BANKS and financial services require Javascript to log in. Nice to know such critical web services are designed by people who "care about customer security." (cough, cough)
NoScript seems to be a reasonable compromise. No browser I'm aware of takes this approach by default.
I'm still waiting for someone to come up with a nice pun involving the title of this news item and Steven Seagal! :D
;D
I'm out for justice
First the MS cursor exploit, now this. How are we supposed to surf the web, anymore? That's it! I'm going back to Morse Code:
_-_- ___ __ - __- - _ --- ___ __ - --- _ ___ -__-
Well, there's spam egg sausage and spam, that's not got much spam in it.
I'll ignore the debunked *XML is S-expressions* bait for the chance to second your critique of JavaScript and the inherent problems with the AJ part of AJAX.
illegitimii non ingravare
With ajax, you're essentially opening up the guts of your application to the world, both the server and client side are wide open to exploitation, neither side can trust the other. It's a security nightmare, far more difficult to secure than your regular client/server application.
Deleted
There, I fixed that for you. But feel free to continue to make sweeping generalizations - that way my contention that 95% of all developers are idiots will continue to be correct.
moderators like to fuck goats.. trust me on this one
> Like building a submarine out of swiss cheese.
I suspect a submarine built out of a nice solid gruyere would probably not be terribly seaworthy either. When it comes to the structural integrity of hull materials, cheese tends to rank pretty low.
Done with slashdot, done with nerds, getting a life.
>First, some web apps parse JSON notation by feeding it into JavaScript's "eval" [json.org]. Now that was dumb. Some JSON support code "filters" the incoming data before the EVAL, but the most popular implementation missed filtering something and left a hole.
Isn't this the same lesson that led to giving up on suid shell scripts? Try to "filter" input to a rich general-purpose language and you always miss something. Especially when the language can be tweaked at runtime, be it with an IFS environment variable or a prototype redefinition.
My first reaction on hearing about JSON was that nobody in their right mind would ever use it.
If you'll permit another pet peeve, the "same origin policy" is already a broken design. First, the same domain doesn't mean the same origin in a world where you can change your DNS record (search on "DNS pinning" for attacks and countermeasures). Second, same site doesn't mean same level of trust. The login page at myspace.com is not security-equivalent to myspace.com/~phisher, and the result was a password-theft incident.
You'd be amazed at what they can do with a good, basic HY80 Cheddar. Just gotta make sure to keep the rats out. They'll get into the bilges and nibble away, and on your first deep dive, bam, you've got flooding!
...the future crusty old bastards are already drinking the Kool-Aid.
Opera 9.10 (like I'm using now) allows per-site (site preferences) enabling of cookies, javascript, plugins, etc., etc. It's not quite right- if you globally disable javascript, for example, it will not run jscript for any site. There needs to be a tri-state control- all on, all off, and per-site. But overall it's great and I feel safer!
Sorry, but I usually disable javascript anyway- never have trusted it, too many crashes with buggy javascript (THAT there should tell you something) and it seems to really slow down page rendering on most pages.
My $0.02
IMHO the most interesting thing about the original article is that the researchers discovered that the exploit worked in a majority of the most popular AJAX code libraries -- that thousands of coders have accepted into common usage -- without detecting the problem themselves. Also, to say that two years of banging on a particular code library doesn't necessarily expose all of the vulnerabilities. That would be like saying that centuries of formulaic banging on Newtonian physics makes Einstein's discoveries irrelevant. That's what good science is all about -- discovering anew what works, and what doesn't in more circumstances than the original science accounted for.
Which is where the old hat new hat post is absolutely correct -- admitting an accepted but untested code library into a production implementation is risky.
Are there any working examples of this problem we could see? I'm having trouble understanding exactly what the issue is supposed to be.
NoScript seems to be a reasonable compromise. No browser I'm aware of takes this approach by default.
IE7 on default install of Win2K3 with latest updates & service packs does this. Whenever you visit a web site that has javascript, it pops up asking whether you want to add it to the trusted sites list, and blocks the script if you don't.
Am I missing something? Doesn't the attacker still need to be able to obtain the victim's cookie? Fair enough, this is not the most difficult task in the world, but if your cookie can be stolen and read by an attacker's site then the fact of AJAX being in the mix seems to be hardly relevant. If someone has your login cookie, why not just go the site with a forged cookie themselves? AJAX might help them to programatically use the cookie to authenticate themselves to the site and request data, but a program that just sends HTTP requests and takes cookies as input could probably achieve the same?
Where is my understanding flawed?
Censorship is the opposite of education. If neo-darwinism were defensible, people would not need to try and censor ID.
I've read the article, and some of the comments here, but can't find any concrete details about what the actual exploit is. All I can find is some vague references to "using javascript instead of xml" for transfering data, and "It's perfectly possible for any one web site to run JavaScript hosted on another domain. Applications such as Google Adsense or Google Maps, for examples, rely upon it." Do "11 out of 12" frameworks really use javascript? I thought JSON was the best method for transfering data (xml is too slow), and you're supposed to run a regex on it to kill any injections before evaling the JSON. I know I certainly do this, and I'd expect more than 1 in 12 of the major frameworks to do it too. As for being easy to execute javascript hosted on another domain, yeah that can be done. But how do you get *your* code to run on a domain that you have zero control over? Browsers are supposed to make this impossible, and if there's a hole this article doesn't tell you what it is. My FUD bells are ringing.
Impossible , An error programing? (another more) , can not be possible! programming is perfect!, bugs are not possible!, fails are not possible!. This should be an error on MATRIX, The Matrix (2.0) have a bug.
If I'm reading the Fortify paper right (I'm in a noisy environment), they say that your proposal will work. The attack is a variation on CSRF, so a similar solution (shared secret nonce) applies.
Things like this are why I have fun in security. Leveraging execute-only access to code into read access to data is a nifty hack.
Now they can go on and babble about a "Web 2.1" or a "Symantic Web" or other punditry.
I want to delete my account but Slashdot doesn't allow it.
So xajax is vunerable to JSON vunerabilities? That might be difficult since xajax only uses XML (the 'x' in xajax)
Interestingly the article says that xajax is vunerable, but then in the PDF report mentions that xajax isn't vunerable because it doesn't use JSON
“Web 2.0” is not AJAX and “AJAX” is not Web 2.0. These terms are not synonyms nor does one necessarily imply the other. Yes, AJAX is an important participant, but Web 2.0 is really about service architecture that is equally consumable by machines and people—a notion that somewhat embodies the original vision of the Web. The article title “Web 2.0 Under Siege” is misleading nonsense. It is analogous to stating that programming is “under siege” because a library exists that contains a vulnerability.
Why bother.
I used to agree with you, because JavaScript has been a huge swamp of errors and compatibility problems.
...
On the other hand
Instant messaging implemented in JavaScript with polling done to the server is really pretty cool, and could not be done without JavaScript.
Reporting new mail on the page, without requiring a refresh, is pretty cool, and could not be done without JavaScript.
Showing who's on the system, in real time, is pretty cool, and could not be done without JavaScript.
Perhaps most importantly, you can use remote javascript templates to make all three of these things happen with the same call, which makes the whole thing surprisingly smooth and efficient.
I agree with you that there are a lot of JavaScript-based functions that are just plain annoying. But there are things that you can do to really help improve the interactivity of your system, and I think those things are well worth doing.
D
How do you keep the other guy from misusing the code when you're sharing the code with him?
What a crock. This has got zero to do with ajax. For example, even with 'insecure' PHP - the first line of any backend ajax code should read something like ..
require_once("include/session.inc");
Where session.inc reads the user cookie (or whatever the authentication mechanism your app uses), and sets up a validated user.
There is NO DIFFERENCE in the way users are authenticated between server side code that renders a regular page, and server side code that is called by ajax. One generally returns HTML, the other generally returns javascript or XML, but as far as authentication goes, they should use the same mechanism.
If your ajax code is capable of returning data that is not authorised, then the problem exists entirely between keyboard and chair. If that is the case with your app right now, then its something you should be able to fix entirely during your lunch break.
I have said it before on slashdot (re the Delphi/PHP thing) - ajax is not rocket science, its just a few extra lines of javascript to your program to call another program and get the results asynchronously. There is NO NEED to buy into some bloated third party 'pointy clicky enterprisey ajax' framework that cannot possibly know anything about your existing authentication methods.
the very users that need to be protected from the code being imported are the ones who will get into the habit of clicking the accept button by reflex.
A warning is better than nothing, but when warnings pop up three to ten times a second, you really can't read every one of them.
And the worst of this is that pretty soon you'll quit looking for telltales that would distinguish between a dialog the suspicious code is putting up and a dialog the system puts up.
(Reference Mac OS X for this. Double click the package, and a dialog pops up to ask for permission to install. Whose could generated that dialog? The only safe thing to do is drag the package onto Installer.app (or right-click and select Installer.app as the application to open it with. You have to assume that there is always going to be another hole that allows executable code to present an icon that looks like something innocent. Any other assumption is not reasonable. I mean, if nothing else, a bundle's icon is containted inside the bundle.)
joudanzuki
lol, wish I had mods points to mod the whole cheese discussion up.
.. and Im sure there exists some cheeses which are not only non-porous, but actively REPEL water .. that would make for a good submarine methinks.
Im sure I have tried once to bite into cheese so hard that it would crack your teeth
MS may deserve scorn for their ANI exploits (already blocked by my virusscanner, thanks for asking), but normally Ajax (at least cross-domain Ajax, the other kind can be done using iframes) is only enabled for sites in your "Trusted sites" list, so at least this problem won't affect you. At least if you disable ActiveX, which you should, I suppose that will be the standard setting today.
Of course the real solution would be that websites can in no way crosstalk to each other unless specific permission is granted. Perhaps there are browser that do that? I found TFA a bit sparse to be honest, I would have liked to see a more detailed picture of the mechanism, and what browsers it works / doesn't work in. And what about the SVG plugin from Adobe? Affected?
Any site can instruct your browser to execute an arbitrary function on another site using your authentication credentials.
/. and browser pr0n and read blogs and another one, on another user account, to do GMail, PayPal and my wire-transfer using my bank's secure website (using a physical device generating tokens to log-in). Oh, and I never use two such Web apps simultaneously and my browser is configured to clear everything (cookies, cache, everything) on shutdown. I go to my bank's website, do my stuff. I close the browser. I want go to GMail: I reopen the browser.
In the face of the countless JavaScript and browser security exploits (even Firefox, which I'm using), I decided a lloonngg time ago to create a special account, that I'm using only to access important sites... But never two such sites simultaneously. So I've got one browser to post on
And I can't help but smile everytime I read about such attacks. Note that there are people even way more paranoid than that: there are people surfing using read-only VMs (like, say, a VMWare player VM running a Windows+Firefox system) and only accessing their bank's website using Live CDs (now good luck on trojaning/sniffing/malwaring that... Sure, sure, the Live CD itself could be compromised, blah blah blah).
They can't run js code in your domain. That's the key point they're all missing.
AFAICT (yes, I did RTFA) the exploit allows the attacker to use a cookie with actually accessing it; the victim's browser happily hands it over when google (or whoever) asks for it. After all, the site name and the cookie namespace match...
Crap. What did the new CSS do with the "Post anonymously" option??
All good points, but you've forgotten the big conditional:
Which is a completely nonsensical restriction
Why not? AJAX just uses a basic http request (ala XMLHttpRequest() or equivalent). How is this http request any different than a non-ajax http request?
Any time you are dealing with an authenticated login, you're either reading the session ID from a cookie or the URL. The ajax request sends the cookie (in the header) or the session ID in the URL of the "get/post", just like a request from a browser.
I have a reason why SOME complex apps could benefit from AJAX: they could make the user interface more helpful and responsive. In my experience, complex apps usually require performance tuning. Enhancing the responsiveness of the GUI could be implemented with AJAX.
You're missing the point of the article/announcement completely. The point there is that the session is still associated with the browser when the user visits another page. So that page, even though it's on a different server, can make the browser retrieve, say, all your emails from your gmail account, and then send them wherever it wants.
Daniel
Carpe Diem
I would say no, since the only alternative to running an application in a browser is to write a client application that people would have to install on their computers.
And finally, it's going to be doing something that I've already made work just fine in a browser, so I don't see the point.
What did I miss?
D
It's simple to defend against. Don't be a wimp; read the original paper at http://www.fortifysoftware.com/servlet/downloads/p ublic/JavaScript_Hijacking.pdf, follow the advice, and all will be well.
If nothing else, look at the Conclusion and Recommendations section at the end.
ASP.NET Ajax, with the default settings, is protected against these attacks.