It may be a bit paranoid, but imagine having a site like myspace, with an exploit used to push a javascript snippet (as has been done), but now, instead of spreading though just myspace, every pageview on myspace will now hammer *your* web server… effectively a ddos attack.

It’s a good thing to have security in mind in the web space.. in IE, you can add the site to your “Trusted” sites, and set security for that context to LOW… would be nice for similar settings for Firefox, etc.. allowing you to override for your apps.. but for the general web.. it’s a good thing.

News just broke that Yahoo mail now includes an RSS reader. Imagine that the script-stripping ability isn’t quite perfect and that someone can execute a script from an RSS item in the reader. With any sort of cross-domain ability (or even an extended image url), XHR can now be used to harvest all that person’s emails and send them off to any given domain.

The vulnerability with supporting cross-domain requests is not of course the owner of the domain but with the possibility of XSS. What I would really like to see as a solution to all these problems is some way of firewalling content within a page.

Imagine that instead of having to strip all script tags, content could just be enveloped in a -firewall- (or whatever) tag that prevented all script execution within it. What an easier place the world would be.

There is a half-cocked solution tot this at the moment which is putting content in an iframe from a different domain. As you make clear in the article above though, the problem with this is that you cannot then modify the content of that iframe from the parent.

What we could really do with is some sort of asymmetric script access. I’m glad I’m not the one that’s got to figure out how to implement it though!

I don’t believe the technique described here opens any new security holes. It doesn’t enable XHR between any two random sites. Both sites have to be in the same domain, and they have to be explicitly cooperating with each other by serving up complementary code.

You’re right of course and to be honest I didn’t catch the fact that they both needed to be specifically communication which does rather change things.

Although it wasn’t meant to be an attack on your technique, I still stand by my original point though which is that cross domain requests carry great dangers. Techniques like arbitrary redirection on the server leave a web application far more vulnerable to attack.

Nonetheless I am very much in favour of having some sort of trusted domains. Web services are great but when they all have to use one domain as a proxy they can become somewhat arduous.

Peter