Re: [cors] 27 July 2010 CORS feedback

On 22/11/2010, at 7:31 PM, Jonas Sicking wrote:

> On Sun, Nov 21, 2010 at 10:41 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> I looked at the most recent specification and noted a few things. Apologies if these are repeats of earlier feedback, but they're still outstanding.
>> 
>> 
>> 1) POST is listed as a "simple method," thereby exempting POST from the "preflight" check. I understand that the rationale for this is that POST already can be automatically generated (by form.submit() APIs), but this does not justify opening a new security hole in the Web; it only makes closing the existing ones more difficult.
> 
> As someone who would love to disable cross-site POSTing, and someone
> who actually has the ability to try to experiment with this on one of
> the most used user agents, I have to disagree.
> 
> The amount of content out there that depends on cross-site POSTing
> using forms is enormous. The amount of content out there that depends
> on cross-site POSTing using CORS is insignificant. Trying to disable
> the former would be such an enormous undertaking that we wouldn't even
> notice the extra amount of work due to the latter.
> 
> I've had this exact discussion at mozilla a couple of times and it
> basically always goes like this:
> 
> other person: Hmm.. we might want to disable cross-site posting for
> forms some day, so is it such a good idea that cors enables it?
> me: If we do disable it for forms we'll just disable it for cors too.
> So much content will break for forms that the cors breakage won't be
> what we're concerned about.
> other person: Yeah, true.

That conversation makes total sense at a browser vendor, yes. From the standpoint of someone creating content, you're still opening a new, and larger, hole -- form.submit still constrains the format of the POST data, whereas with CORS, there is no constraint. 


>> 3) When a server changes the headers in a response based upon the value of the incoming Origin header (as outlined in sections 5.1 and 5.2), it must insert Vary: Origin into *all* responses for that resource; otherwise, downstream caches will incorrectly store it.
>> 
>> Be aware that doing so will cause many versions of IE not to cache those responses at all. Another option would be to disallow varying the response based upon the Origin header.
> 
> Disallowing varying by origin seems like a bigger problem than IE not caching.

Either way, it needs to be addressed. 


>> 5) Using a "preflight" check in combination with a cache exposes sites to DNS rebinding, man-in-the-middle, and potentially other attacks that did not exist before. This should be noted.
> 
> The DNS rebinding issue is a quality of implementation issue. It's no
> problem simply rerequesting the preflight if the DNS resolves to a
> different IP between the preflight and the actual request. I agree
> that noting this in spec is a good idea.
> 
> Could you describe the new man-in-the-middle attacks which did not
> exist before with cross-origin communications?

I suspect we're quibbling over the definition of 'new' here, but can agree that CORS is going to be another tool to attack sites with (which to be fair isn't really its fault; it's just that we should give people fair warning).


>> 6) Requiring a preflight check per-URI is not an efficient use of network resources for applications that use a large number of URIs, as is becoming more prevalent; effectively, it introduces another round-trip for each unsafe request. Handling OPTIONS is also somewhat specialised on many servers. It's also awkward to handle OPTIONS per-URI on many servers. I've raised this several times before, and am still not convinced that the underlying requirement (#8) justifies such a convoluted and ill-concieved design, or indeed is effectively met by this design.
>> 
>> Allowing a site to define a 'map' of where cross-origin requests are allowed to go would be more efficient in most cases, would be vastly simpler to implement for servers, and would be similar to many other site-wide policy mechanisms on the Web.
> 
> We had a design in place which allowed preflights to apply to multiple
> URIs. However there were too many issues with servers resolving URIs
> in weird ways which made us drop it. One concrete example was that
> some versions of IIS UTF8 decoded URIs and then ignored bits above the
> lower 8 bits. This made it treat URIs as if they contained ".." when
> the browser had no idea of this.
> 
> In short, CORS felt like the wrong spec to start relying on servers
> not to do strange URI handling.


I'm not sure what you're referring to, but there are clean ways to do this without resorting to depending on how servers interpret URIs.

Regards,


--
Mark Nottingham   http://www.mnot.net/

Received on Monday, 22 November 2010 08:40:38 UTC