On 22/11/2010, at 7:53 PM, Jonas Sicking wrote: > > Practically speaking, the only constrains on <form> submissions > request entities is that they contain a '='. Using text/plain encoded > forms you can submit any content with that restriction. > > Further, I believe that flash allows cross site POST submission with > arbitrary data, i.e. even data without a '='. But I haven't looked > into that in more detail.
Perhaps. I still don't think it's great for the W3C to standardise yet another method of sending cross-site POSTs without permission. >>>> 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. > > You mean by adding a note in the spec? Are you adding a similar note > to http-bis about the Vary header? RFC2616 already defines Vary: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44 ... and bis refines it: http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-12#section-3.5 >>>> 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). > > I'm not sure adding ominous "There might be ways that this spec can be > used for cross site attacks. Try to take precautions" notes to the > spec are much more useful then the "There is a general threat, but we > don't have any more specific information at this time. People should > be aware of their surroundings." alerts that the Department of > Homeland Security sends out :-) That's the second straw man you've used, Jonas. Please stop. >>>> 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. > > I'm sure proposals are welcome. I'm pretty sure they're not, based upon past experience. We've been through this a few times already. Regards, -- Mark Nottingham http://www.mnot.net/
