Tuesday, February 14th, 2006
Debunking Strong Misconceptions About Cross-Domain Ajax Security Issues
Category: Ajax
, Programming, XmlHttpRequest
On the Technoblog, there’s a new post that seeks to debunk misconceptions about some of the issues that have come up surrounding the use of cross-domain Ajax connections.
Quite a number of people have been discussing possible cross-domain Ajax security issues recently. These are smart people that generally know their technologies very well, but for some reason are missing some fundamental aspects about Ajax.
There are a few articles that he points to as misrepresenting some of the issues - things like resource theft, cross-site scripting, slowing down other people’s sites, and session data issues.
He goes through each of these (and more), explaining how most of them could be avoided with a bit more thinking on the developer’s side of things rather than blinding assuming connections/resources when creating applications. Also, be sure to check out the comments on the post - a back and forth between the post’s author, Lucas Carlson, and Jason Mauer.
Lucas seems to dismiss AJAX ability to DDOS as “the server can do it too”. Block one server, possibly get it shut down and your done. How do you deal with all those clients with differing IP’s constantly posting forms, etc, to your site? I understand that there are multiple ways to do this outside AJAX, but the point is AJAX makes this easy and it shouldn’t.
Cross domain ajax does not make it any easier than by doing DDOS like this:
while(true) { (new Image()).src = “http://targetsite.com� }As I said many times already: Cross-domain Ajax does not introduce any new security concerns. Anything malicious that can be done with cross-domain Ajax can be done almost as easily today with today’s current level of browser security.
Another problem is to post data to forms the “victim” user would not otherwise post to. Polls, blogs, petitions, the list goes on. As a developer I would want this ability, but as an informed user I dont like it. As a developer I can use my server as a proxy as does Flash remoting, etc. There is really no neccessary pros to this only problematic cons.
Just dumping a link: http://www.modsecurity.org/archive/amit/exploiting_the_xmlhttprequest_object_in_ie.txt
Would be worth asking the author for his feelings on cross domain AJAX.
[...] Like it or not, there’s plenty of people who want to do cross-domain remoting. The typical technique is via script tags, and since this means the response must be valid Javascript, JSON is usually the message format. But what if you want to grab some XML instead of a JSON-formatted object? Dave Johnson explains how to achieve cross-domain XML, building on the standard script tag trick. [...]
I will post an example on my blog tonight or tomorrow showing that IE is reading cookies through a XHR request from another site. With more manipulation of the code, someone can easily figure out ways to read people’s emails if they are stupid enough to click the “allow” button with the cross domain request. I have not bothered trying to do it through Mozilla with the privileges.
Eric
Lucas,
although you are of course right that a DDOS attack could easily be done with images there is another cross-domain issue that you don’t address. That issue is password-cracking.
With the ability to do cross-domain scripting I now also have the ability to do a brute-force attack on any server I chose. My army of zombie machines is as large as my website audience and each one of those machines can be used to execute guesses until they finally get locked out of the target site.
This could of course be done using my server but as Jason Mauer pointed out, it is far easier to block a single server than a million browsers.
There would of course be ways for servers to defend against such an attack but the fact remains that most of all web-apps will be instantly vulnerable.
(Note: I am the author of the OWASP Guide 2.x, and currently researching and writing the Ajax security chapter for it)
Lucas’ article is partially correct, but also misses the point.
For most transactional systems, sending the XMLHttpRequest to a second server is a terrible security outcome:
a) it prevents access to the first server’s session object, which is usually where the authorization is stashed
b) the second server could get the first server’s authorization state… somehow (there are methods), but many are sub-standard. In my investigations … including my work for the last week - I have an open Paros window beneath this browser window with a real life “enterprise” Ajax application running in a major bank… the authorization is a simple clear text string - unacceptable
Yes, developers *could* spend a bit more time thinking about the security implications of second server submissions, but I for one like the fact that the browsers in general block it.
The Ajax chapter is nearly complete. I am waiting for accessibility peer review, and once that’s done, it’ll be put out for widespread peer review prior to Guide 2.1’s release. If you have a specific desire to peer review it, and are a mad skillz Ajax developer, please contact me at vanderaj (at) owasp.org and I’ll send you the chapter.
Andrew
Anyone knows the restriction is the same domain but what about those with multiple IPs (round-robin load balancing), does it resolve the hostname again or just use the cached IP? My test showed that it uses the cached IP address. Is there a way around this?