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.

Posted by Chris Cornutt at 3:12 pm

3.6 rating from 37 votes


Comments feed TrackBack URI

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.

Comment by Noone — February 14, 2006

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.

Comment by Lucas Carlson — February 14, 2006

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.

Comment by Noone — February 14, 2006

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.

Comment by Harry Fuecks — February 15, 2006

[…] 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. […]

Pingback by Ajaxian » XML Messages with Cross-Domain JSON — February 15, 2006

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.


Comment by Eric Pascarello — February 15, 2006


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.

Comment by Peter Nixey — February 17, 2006

(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.


Comment by Andrew van der Stock — March 7, 2006

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?

Comment by Son Nguyen — March 19, 2006

Please correct me if i am wrong, the code listing in Ajaxian » XML Messages with Cross-Domain JSON is not working on IE

Comment by JulianW — February 17, 2009

Leave a comment

You must be logged in to post a comment.