On Sat, Apr 24, 2010 at 10:04 AM, Tyler Close <
tjc...@google.com> wrote:
> On Fri, Apr 23, 2010 at 6:51 PM, Dirk Pranke <
dpr...@chromium.org> wrote:
>> CORS extends the functionality of UMP in the following ways (roughly speaking):
>> * It allows methods other than GET and POST, at the cost of requiring
>> a "preflight" request to see if such a request is allowed. The
>> response to the preflight request is cachable.
>
> Note that this preflight request is *per URL*. If a PUT requires two
> round trips and POST only one, I suspect an API designer will have a
> tough time defending the use of PUT, no matter what its philosophical
> advantages. Consequently, I think its fair to wonder if CORS enables
> methods other than GET and POST only in theory and not in practice.
I am inclined to agree with you here, but I am usually skeptical about
claims that "PUT" is a useful verb in practice.
>
>> - I am less convinced that sending the Origin header is also
>> undesirable. I think doing so can enable a simple class of use cases
>> trivially at a relatively minor risk. Perhaps Tyler or MarkM can chime
>> in with the sort of attacks they're worried about here, in case I'm
>> missing something.
>
> I have a few concrete concerns with using the Origin header in UMP:
>
> 1. Consider a resource that uses client IP address or a firewall for
> access control. The resource author might easily think CSRF-like
> vulnerabilities can be prevented by checking the Origin header. The
> logic being: "This request came one of our trusted machines behind our
> firewall and was sent by one of our web pages. It must be safe to
> accept the request." Of course if any page from that origin is doing
> cross-site messaging then the target site could run a Confused Deputy
> attack against the intranet resource. In particular, consider an
> intranet page doing cross-site messaging with an API like the Atom
> Publishing Protocol. The Atom server is expected to respond to a
> resource creation request with the URL for the created resource. This
> URL is expected to identify a resource created by the publishing site;
> however, if instead the target server responds with the URL of the
> victim intranet resource, then the intranet page will POST to that
> resource. The intranet resource receives a request from behind the
> firewall with the expected client IP address and the expected Origin
> header.
(I wrote this part last night but didn't send it because I wasn't
happy with it yet; Aaron's reply largely makes this part moot ...)
I'm sorry, but I didn't follow this example or what the perceived
threat is at all. I've been feeling rather stupid lately, so this is
probably my fault, but could you be a bit more explicit about who is
doing what to do who here, and what is being compromised? I think
you've got "
cms.intranet.example.com" (which is the atom server), and
"
client.intranet.example.com". I'm not sure what "target site" is
supposed to refer to, nor "target server", "victim intranet resource",
or "intranet resource".
Presumably the end result is that "cms.intranet" gets a request from
"client.intranet" that it honors, but it shouldn't?
At any rate, let me try and go back to the beginning.
(1) I think at this point, everyone acknowledges that confused deputy
attacks are a real threat with CORS. It is also acknowledged that they
can be defended against at the cost of increased developer complexity.
(2) Most everyone acknowledges that UMP is (or will be a subset) of
CORS, and so UMP will likely be implemented. Since it is clear -- to
me at least -- that a no-ambient-authority version of cross-domain
messaging should be possible, and it's almost no work to implement
this on top of the CORS infrastructure, we should go ahead and do so.
(3) CORS is, at least in WebKit and in most other browsers, already
implemented and deployed, so debating whether or not it should be
implemented and deployed is moot. Rather, the questions become -
should it be documented and/or evangelized at all, and should it be
removed?
Now, when deciding whether or not to use or remove a protocol, we
should ask the following questions:
1) What is it being used for? Are any of those uses secure enough that
we need not be concerned about them? We don't know the answer to these
questions, so some amount of information gathering would be good.
Slightly different, what can it be used for, and are those uses
secure?
If it can be shown that no usage of CORS is secure, that would
obviously be a deal killer. However, that's not going to be possible,
since you clearly can build secure apps on top of it, as we've
discussed above.
2) If CORS is being used securely, can the equivalent functionality be
achieved other ways, just as easily and securely? Answering this
effectively probably also requires the information gathered in (1).
Otherwise, it is too easy to create strawman use cases on both sides.
One could largely object that we should not have a protocol floating
around out there that has known holes. Unfortunately, since CORS
builds on the existing web infrastructure, the cat is long since
escaped from that bag (although we could at least suggest that the
aspects of CORS like non-GET/POST usage should be discouraged, if we
were being paranoid). The CORS advocates suggest, probably correctly,
that CORS has the advantage of making certain coding patterns much
easier than they are otherwise in which case it becomes easier to
write correct versions of the cross-origin sharing code that does
already exist today. And that's a good thing.
One can also object that CORS may encourage people to adopt and spread
insecure communication patterns (leading to more cross-origin sharing
than currently occurs). I suggested at the beginning that we not
encourage this and hence CORS continues to exist in the same limbo it
currently lives in, at least until we can get better answers to (1)
and (2).
The last problem with adopting a "UMP-only" world view is that we
don't actually have a good sense of what the security issues around
UMP-only messaging will be. I think we would agree that as long as
URLs are correctly made unguessable and aren't leaked, things should
be good. That is, however, a largely academic stance, just as saying
that you can use CORS successfully (or not) is an academic stance. We
need real world usage to get a much better degree of confidence here.
-- Dirk