Web 2.0 is vulnerable to attack
by Jeremy on Apr.02, 2007, under Uncategorized
I found this to be an interesting read. Apparently, JavaScript frameworks that are using JSON to handle their XHR / AJAX are presently vulnerable to “JavaScript Hijacking” – Vulnerable frameworks include Microsoft ASP.NET AJAX (aka. Atlas), XAJAX and Google Web Toolkit, Prototype, Script.aculo.us, Dojo, Moo.fx, jQuery, Yahoo! UI, Rico, and MochiKit.
April 2nd, 2007 on 2:07 pm
I don’t understand, it’s impossible to send an AJAX request to a domain other than the current domain. The only exception to this is using iFrames but that’s an old vulnerability and is how the sausage attack works. I don’t see how JSON has any difference? JSON is used to communicate from the server to the browser, and only the server has control over that.
It doesn’t make sense.
April 2nd, 2007 on 2:15 pm
I’m going to keep a lookout for the whitepaper mentioned in the article. I’ll put a link up to it when I find it, or if someone else could pass it along, that would be great. I was confused at first, myself, and I would say how I think it works… But, I’m going to read the whitepaper first to make sure I’m not completely off-base.
I’ll put up more details as I see them.
April 4th, 2007 on 3:13 am
Okey poke. Would be interesting to know.
April 4th, 2007 on 3:10 pm
Ok I did a bit of research, and here’s what it is:
1. The CRSF hack allows you to make an iframe that will allow you to perform requests on sites (and so it sends the cookies and authenticates you). By the cookie spec, this shouldn’t be allowed but to most modern browsers do this anyway.
2. Although the browser lets you send the request, cross domain rules prevent you from reading the response (the contents of the iFrame).
3. However, because JSON is Javascript that is eval()ed, it is eval()ed and then the response is thrown away.
So far, no harm (apart from sending the request in the first place
). But the problem is, Javascript’s core functionality can be changed. Most importantly, the array/object constructor can be changed. This means that when the JSON is eval()ed, you can manipulate the array constructor to still pass the response before it’s thrown away. Thus allowing sensitive data to be taken.
April 4th, 2007 on 3:22 pm
Also, I just thought I’d post the best solution to the CRSF hack (which will effectively fix the JSON array hack since the request will never be accepted).
Basically, a piece of Javascript grabs the cookie information and sends it as a post/url to the submitting page. Because the hacker can’t actually get the cookie information, they can’t send the cookie information as the url/post. You then check the submitted data with the actual cookies, and if they don’t match you unset() the cookie or whatever. At least that’s how I think it works.