Re: [cors] 27 July 2010 CORS feedback

I guess I didn't put that very well. This is more a general comment on the
discussion rather than a relpy to a specific post.

If I can forge requests to web sites (for example using "curl"), then any
site that does not impose security checks on its input values is asking for
trouble. Making security depend on headers which can be forged seems like
false security to me.

So I see no problem allowing POSTs to any URL, providing the POST cannot
assume any authority on the part of the user. That way a POST can do no more
harm than a script using "curl".

The solution to the POST authority problem would seem to be to apply the
origin rule for cookies (which seems sufficient to me) consistently (perhaps
it already is?)

So CORS seems to me to be about permitting exceptions to a security policy,
not about fixing that underlying security policy. I don't think any changes
to the CORS spec can fix a broken underlying security policy. Perhaps I am
missing something though?


Cheers,
Keean.





On 22 November 2010 09:28, Keean Schupke <keean@fry-it.com> wrote:

> It this spec the place to fix cross site vulnerabilities? Would it not be
> better to restrict cookies to only be sent when the domain of the page you
> are navigating away from matches the cookie domain, as well as the page you
> are navigating to?
>
>
> Cheers,
> Keean.
>
>
> On 22 November 2010 09:10, Mark Nottingham <mnot@mnot.net> wrote:
>
>>
>> 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/
>>
>>
>>
>>
>>
>