That said, the article appears to spout FUD more than any credible security vulnerability in either the specification or Mozilla’s implementation.

The same-origin policy on the web is not the end-all-be-all-solution for proper sandboxing. The same-origin policy greatly limits the type of applications that can be built.

Kudos to Firefox for implementing this. Properly secured, this capability will open the flood gates to an entirely new wave of interoperability and application richness on the web.

Yes. Yes it is.
- Dan Veditz (Mozilla)

P.S. you can play with the proposed Firefox 3 implementation of this feature _today_ by downloading a nightly build. The $500 Mozilla Security Bug Bounty applies if you can demonstrate an actual data-stealing same-origin violation in it, no need to wait for the actual release. We’d much prefer to know now, in fact.

First of all the comments are always open. Everyone can comment! Second, I am not sure if I am mistaken or you guys are fighting for the wrong cause. I am going to quietly wait until u guys come with Firefox3 and then we all will see whether your specification is inherently insecure or not. I hope not.

To repeat, IMHO u have some quite obvious security gaps. I am referring to the specifications outlined here (XMLHttpRequest level 2, Editor’s draft 9 August 2007) and here (Enabling Read Access for Web Resources).

Let’s have a brief overview of your mistakes, the way I see them:

First of all

You perform the access control checks after the request was completed. This is insane! You are saying that CSRF attacks are known for ages and you are not really contributing to the greater evilness of the Web. I must disagree. CSRF attacks via Forms (POST and GET) or Images (GET) and Links (GET) cannot contain additional headers. They do not have fine-grain over the data that is submitted. Therefore, your method makes the whole situation more insecure. I highly recommend to read Wade’s excellent paper on Inter-Protocol Exploitation for more ideas how your approach can be abused.

Second

None of the cpecs explicitly specify what methods should be used with your access control system. I am sure that you are both great coders and have a lot of good stuff to offer when it comes to specifications and design, but I am breaking into WebApp applications all day long. I’ve probably seen stuff that you guys cannot even imagine. The world is not perfect. I highly recommend to consider implementing a METHOD restriction, such as only GET and POST have the ability to perform cross-domain operations.

Third

The whole idea of cross-domain communication is just plain insecure. I am not saying that Adobe’s crossdomain.xml implementation is any better. I am just implying that we are going to have a lot more problems then now – all of them trust related. Good that only Firefox is going to implement these specs so Internet is not going down, yet.

Finally

I am not completely sure whether your specifications will result in more accurate port scanning with JavaScript. Maybe I am just day dreaming. But I don’t care. As far as I am concerned it is your job to make sure that this doesn’t happen.

Before you flame me back, please take my points as just pure critic on the specifications, nothing personal. We are all grownups here, no matter who is mistaken we shouldn’t really convert the entire matter into a war. I’ve made tones of mistakes in my life and I hope that I make even more in the future. There is no better way to learn new things. Making mistakes is not a really a problem. The problem is not being able to react properly when they happen.

Otherwise, if we all agree that there might be some problems, even if they are minor for now, let’s sit down and work them out. Let’s not leave pride and other elements prevent us making the world slightly better place.

P.S. so far my research has caused only trouble :) however, don’t shoot the messenger!

I don’t have much time to read the spec again but by skimming through it very quickly, I stumbled across the following:

A conforming user agent must support some version of the HTTP protocol. It should support any HTTP method that matches the Method production and must at least support the following methods:

• GET
• POST
• HEAD
• PUT
• DELETE
• OPTIONS

So u guys are not explicitly preventing TRACE, which potentially, again I repeat, potentially can lead to some problems.

Moreover, logically, ready state 3 should fire no matter the security restrictions. Am I wrong?

Ronald said:

they are violating the same origin policy

He is right. Ignore the all specifications problems that we’ve discussed so far. We don’t know whether they are going to by present in Firefox’s implementation. Let’s concentrate on the fact that attackers will be able to obtain sensitive information from multiple sites by compromising only one of them. The trust relationship that will be built on top of the web will be used in the most undesired ways.

Let’s say that Yahoo wants to enable all of their service to communicate with each other but only for their domains. This is cool – sort of secure. However, if the attacker manages to get only one XSS on any of the trusted domains, they effectively can get interesting info from all the others. To me, this is like back in 1990 – everything is broken again.

I’m not sure where TRACE is coming from. Earlier versions of the XMLHttpRequest spec explicitly disallowed it, and that’s certainly true of the Firefox implementation. Regardless of spec I can’t see Firefox re-enabling support for TRACE in XHR.

Firefox 3 nightlies already implement cross-site XHR support, I encourage you to play with it and poke holes based on reality rather than mangled press reports.

If a web server has a CRLF injection problem then that’s a problem regardless of this new feature. It could, for instance, lead to an XSS problem which allows equivalent data exfiltration to what you worry about here.

Your port-scanning example is a great one, I’ll find out who to bug to get the spec changed to skip or delay state 3 for cross-domain requests. Thanks!

If the FF XML engine is vulnerable to a buffer overflow then you exploit FF directly by loading an XML page or frame. XHR doesn’t change a thing.

I’m disappointed not seeing anything in the spec about preventing the reading of cookies or other sensitive headers in cross-site requests. That needs to be made explicit.

Brian, we can add a lot of preventing mechanisms on the client but they all seams to be hacks and look a bit ugly and not on place. CRLF is a valid character sequence and if developers wants to use it for whatever reason, they should be able to. As for the extension, yes you can. Check Tamper Data source code.

But it seems strange that the browser actually has to make a cross-domain request and receive a response in order to determine whether or not it is allowed to look at the response. That’s just asking for trouble.

service.xml?someparam=blab%0B%0AContent-Acce….

Shudn’t it be %0D%0A ?