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.
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.
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.
Just serve up an animated cursor before any XML handshakes. This will stop the attackers from exploiting the AJAX piece.
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."
BBZZZT! I'll bite... "Web 2.0" is a term coined by Tim O'Reilly (of O'Reilly Media; you know, those books with the animals on the cover) as a way of classifying a new generation of web-based applications, a shift from static text and html to interactivity and user-participation in creating the content of a site. The media picked up on it later and gave it buzzwordyness. People who do not have a background in and/or an understanding of technology assume that the media made it up.
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/
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.
> 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.
All very well and good until one of those ten gets infected by something nasty. I seem to recall seeing an article recently where a big site like CNN or one of them got hit by a worm and was actually serving up infected pages for 48 hours or so till it was discovered and cleaned out. The solution is not to rely on the servers being secure (although that can't be ignored either if you're securing the servers), but to ensure that even IF the servers are compromised that you arn't vulnerable.
As much as I hate to admit it, Vista is actually close in it's security implementation, the user really should be required to approve certain actions, just not every action. A more robust security model, such as the one used in SELinux (with a more sane administration interface), combined with some user confirmation such as that used in Vista would lead to a much more robust OS. Add to that more secure apps running in at least partially sandboxed environments and possible infection vectors would be reduced to almost nothing (not nothing mind you, but much better than today).
Applications should be designed like banks, secured and fairly well defended. OSes should be designed like Area 51, armed and not afraid to shoot.
Ultimatly of course, it's up to the user to be the last line of defense, so even though we can do alot to make the users life easier, the final part of the puzzle is user education.
Curiosity was framed, Ignorance killed the cat.