Slashdot Log In
Web 2.0 Under Siege
Posted by
Hemos
on Mon Apr 02, 2007 10:22 AM
from the in-dark-territory dept.
from the in-dark-territory dept.
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'"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
XSS (Score:2, Interesting)
Re:XSS (Score:5, Informative)
Daniel
Parent
Re:XSS (Score:5, Informative)
Daniel
Parent
Re: (Score:2)
Re: (Score:3, Funny)
Here [fortifysoftware.com]. For future reference:
It's really not that hard to find details. All you really need is the ability to operate a web browser, a search engine, and about thirty seconds of your time.
Re: (Score:3, Informative)
Re: (Score:2, Informative)
--Anonymous Coward
Vocabulary Fix (Score:3, Funny)
Re: (Score:3, Funny)
Okay, I'll be the first to ask. (Score:5, Insightful)
"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."
Re:Okay, I'll be the first to ask. (Score:5, Informative)
Let's say someone wants to attack my site, amazing.com. I browse to their site, remarkable.com, and the exploit code gets loaded into my browser. Remarkable.com can post to amazing.com using AJAX and receive replies as though they were authenticated on my site, because the browser automatically sends the amazing.com cookies with it when accessing an amazing.com URL. It appears to the browser fundamentally as though I was in remarkable.com and then typed the amazing.com URL on to the address bar.
(Of course you could spoof the referer but not from an existing browser session so I think the referer can be relied on in this context.)
If this is so, then it could truly be a throbbing migraine to fix - you would have to use the HTTP referer field to verify that the site calling your Ajax code was valid.
Hope that helps. Not the cheeriest news this morning
D
Parent
Re:Okay, I'll be the first to ask. (Score:5, Informative)
No, that kind of thing has always been possible since the very first implementation of JavaScript. If you don't need POST, then you can even do it with plain HTML 2.0, no JavaScript.
The problem here is that JSON is a subset of JavaScript and so it is automatically parsed under the local domain's security context when it's included in a document with <script>. There's a few tricks to "hide" it even though it's already been parsed and is sitting in memory, I assume these guys have found a way around that.
Parent
Re:Okay, I'll be the first to ask. (Score:5, Informative)
No, that's the vulnerability. This allows other domains to get the data when the applications don't want to share it.
The news here is that the "additional precautions" that most Ajax libraries take are ineffective.
Parent
Re: (Score:3, Informative)
You're right, they're right. It's from March 12th, 2007 and it's a different issue than the one I mentioned before.
Putting the JSON data into comment tags or Google's while() approach sound like good defense mechanisms.
Also, using auth tokens in addition to cookies can defeat most scenarios as well (just ensure not to return a valid auth token in any replies that don't require a valid auth token already).
Re: (Score:3, Interesting)
Re: (Score:2, Informative)
Such an attack previously succeeded on Digg (in the form of a white-hat demonstration of a self-Digging website), but that vulnerability has already been patched. The description of the demo attack, which they also refer to as "session riding," is available here: http://4diggers.blogspot.com/ [blogspot.com]
Re: (Score:3, Insightful)
Re: (Score:2)
If you can inject the JavaScript needed to do this you can usually also get it to read webmail etc. I won't repeat the things given by others that di
XSRF (Score:2, Interesting)
http://en.wikipedia.org/wiki/Cross-site_request_f
Re: (Score:2)
quick! (Score:5, Funny)
Web 2.0 SP1? (n/t) (Score:2)
Re: (Score:2)
Duh (Score:3, Informative)
Mashups? (Score:5, Funny)
Does this mean... (Score:3, Funny)
Where's the problem? (Score:5, Interesting)
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
Re:Where's the problem? (Score:4, Informative)
AJAX really do need sessions. Just think of Gmail. It it a single AJAX session starting when you login, and finishing when you logout or timeout.
If AJAX don't use sessions, it would have to authenticate itself with username and password with each request it made to the server.
An better solution might be to let the AJAX application explicit handle sessions by storing the session id, and sending it in the post part of all it's requests. But that might be a problem with the browsers history, because it would then loose your session id, if you used the back button.
Parent
Re: (Score:2)
You don't run into this specific problem if you do that. New windows with the same domain name (e.g., gmail.com) don't share the same memory as the original window, thus it won't have the authentication token, and won't have the active cookie, either.
Re: (Score:2, Informative)
Store then in javascript? Huh?
It is completely normal -- across the entire industry -- to store session identifiers in cookies. There is nothing special or AJAXy about that.
Shirky's Law: (Score:5, Interesting)
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.
Re: (Score:3, Informative)
Riiight. Facebook is absolutely secure and immune from security problems [digg.com] and spam [wordpress.com] because of their preventative measures.
Is that title sarcastic? (Score:4, Insightful)
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.
We've already seen this before (Score:5, Interesting)
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.
Re:We've already seen this before (Score:5, Informative)
http://getahead.org/blog/joe/2007/01/01/csrf_atta
Of course, DWR 2.0 will have all this goodness built in.
Parent
Easy Fix (Score:2, Funny)
Leaves web to trusted sites only (Score:2)
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 vi
Backwards quote... (Score:2)
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... (Score:5, Funny)
(Captcha: backtotheweb1.0)
Detailed report on this problem (no reg required) (Score:3, Informative)
sigh (Score:5, Insightful)
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."
Re:sigh (Score:4, Interesting)
That'll be because it is. It's basically an observation that CSRF on a site which returns data in JSON format allows the attacker to read the content of the result. Well, duh. Of course that happens. It's one of the reasons I've always opposed JSON as a useful format.
The other reason is equally bad, but only applies to "mash up" type situations: the coder of the client has to trust the server with access to all data in the client. This makes it useless in many situations.
The best solution would be to scrap the current security system, make subrequest cookies (including XMLHttpRequests) dependent on both the domain the request goes to *and* the domain of the page that caused the request, and allow XMLHttpRequest to access servers other than the page source. This would both fix CSRF and eliminate the need for JSON. What more do you want?
Parent
vulnerable == cookie && json && !p (Score:3, Informative)
- 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/
i told that EVERY time AJAX - 2.0 hype was posted (Score:4, Interesting)
XML is so last week. What's really wrong. (Score:5, Informative)
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" [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. Second, there's an attack similar to the ones involving redefining XMLHttpRequest: redefining the Array constructor. [getahead.org] (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.
Re:XML is so last week. What's really wrong. (Score:4, Interesting)
You don't say. My first thought on hearing about the entire idea was "why would you want to let a foreign server run its code on your page?"
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.
Err... if I don't let foreign code execute (e.g. by doing 'var e = document.createElement("script"); e.src = "http://www.someotherserver.com/potential-securit
The last attempt to fix this problem involved adding restrictions to XMLHttpRequest, but that only plugged some of the holes.
The fix seems obvious to me:
* cookies in subrequests must be tied to the domain of the page that initiated the request as well as the domain the request goes to; this reduces the possibility of CSRF. So if www.a.com has a web page that requests data from www.b.com, it will only send a cookie if www.b.com set one in response to a previous request from www.a.com. This applies to SCRIPT tags, to IFRAME tags, to IMG tags, to LINK tags, etc.
* XMLHttpRequest must not be tied to the same-domain policy. Attempts to access a different domain should result in a request for confirmation from the user for the first time any particular requester/receiver domain pair is used. This means mashups (and other applications that need cross-domain access) can be written that do not need to use JSON. JSON parsing through script insertion or eval() is insecure, and should be deprecated.
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.
Scripts, yes. I don't see the need to ensure that data originates in the same domain.
Parent
Old truths new truths... (Score:2)
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 count
Re: (Score:3, Informative)
Re: (Score:3, Funny)
Re:Executing 3rd party code by default is insecure (Score:3, Funny)
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.