Thursday, November 24th, 2005
Cross-Domain Ajax. Security Implications in Depth
Category: Security
He talks about the areas of concern:
- Resource Theft: Resource theft can happen when Jack Innocent visits the website of Evil Bob. Evil Bob has written some XHR code that repeatedly requests compute expensive pages from the site of Victim Inc. Thus Evil Bob gets to use Jack Innocent to do his nasty work.
- Cross Site Scripting: Should we ban cross-domain XHR because of XSS attacks? I’m not sure, but be sure of this: there are plenty of ways to allow XSS attacks on your site without cross-domain XHR.
- Slow 3rd Party Web Sites: If you design your website to use thousands of small requests then you are asking for trouble – so don’t do it! Likewise if you design your website to depend on a slow resource then expect your website to be slow. Eric is right in saying that proxy caching is a great solution to this problem, but let’s not ban cross-domain XHR because people can do silly things with it.
I am personally waiting for trusted domains. It would be great to be able to say “mydomain.com trusts yourdomain.com and hisdomain.com”.
The server side could have a say in the matter too. If you want to offer your web service to the world to do whatever they want, then you should be able to say “let anyone talk to me”
What do you all think?
Should we open this all up?
Related Content:
3.3 rating from 4 votes
Absolutely not, because of the intranet theft problem – which is the reason JavaScript (in the time before Ajax) has a same-domain policy enforced for code involving frames in the first place.
Say I work for big-corp.com, and when I’m hooked up to their network at work I can access a private intranet at intranet.big-corp.com. Without the cross-domain restriction an attacker could add some code to their page which silently retrieves intranet.big-corp.com/top-secret-memo.html and posts it back to their site using XHR.
Resource theft can be done anyway with DOM manipulation or even (new Image()).src = “URL”, so you might as well strike that off the list.
Intranet theft is a real issue, but if your intranet used HTTP authentication on your intranet, like you obviously should, then there is no problem.
Slow websites are slow websites.. we can already do that. XHR actually lets you mitigate it by controlling when things get loaded and it gives you the opportunity to deal with timeouts and slow resources on a case by case basis.
Flash addresses this issue with the crossdomain.xml policy file. A crossdomain.xml file on a server specifies who (by domain) can access what resources. For example, Apple keeps their content locked down…
http://www.apple.com/crossdomain.xml
… while Yahoo! opens up their APIs to the world…
http://api.search.yahoo.com/crossdomain.xml
I think this approach works well for everyone.
Christian
Flash’s crossdomain is a rather silly approach to the problem, but I’m all for it if that’s what it takes to get the browser developers and security community to allow web developers to do cross-domain services.
I think that’s unlikely, though.
Bob, if you’re going to call it silly, can you at least explain why? If you have some ideas, I’d love to hear them. I’ve always thought of Flash’s security model as an excellent solution.
Christian
I disagree with almost all of your conclusions and would love to discuss further.
http://tech.rufy.com/articles/2006/02/09/debunking-strong-misconceptions-about-cross-domain-ajax-security-issues
I can’t help think that Lucas’ article dodges the problem by defining AJAX as “good things that people do with XMLHTTPRequest.” I’d leave that comment there (as well as some more concrete points), but unfortunately, comments have been closed on that entry, so I can’t.
As Simon and others point out, there are lots of bad things that can if you open up the security model on XMLHTTPRequest. They may not be “AJAX” (whatever that is), but they’re serious concerns regardless.