Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

You are conflating so many different issues that it's impossible to make an
argument regarding any one of them because you just start talking about a
different issue in which the argument is different.

CORS is a fine way to protect your bandwidth against other sites embedding
your resources, because this use case has nothing to do with security.  If
someone manages a CSRF attack that allows them to embed your resource, it's
probably not that big a deal -- the only thing at stake is bandwidth, and
few people are going to go to great lengths to steal it anyway.

The problem we're getting at is that CORS is being presented as a security
mechanism, when in fact it *does not* provide security.  Yes, CORS is
absolutely easier to use than UM in some cases -- I don't think anyone is
going to dispute that.  The problem is that the security it provides in
those cases simply doesn't exist unless you can ensure that no resource on
*any* of your allowed origins can be tricked into fetching your "protected"
resource for a third party.  In practice this will be nearly impossible to
ensure except in the most simple cases.

We believe that CORS is harmful because it falsely claims to provide
security that it cannot practically provide in most cases.  Users who rely
on this will get burned.  We believe that standardization of CORS will lead
to a huge new proliferation of CSRF vulnerabilities, and the eventual result
is that anyone serious about security will ban its use on their servers.

On Mon, Dec 21, 2009 at 4:17 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Mon, 21 Dec 2009, Tyler Close wrote:
> > On Mon, Dec 21, 2009 at 2:39 PM, Ian Hickson <ian@hixie.ch> wrote:
> > > On Mon, 21 Dec 2009, Tyler Close wrote:
> > >>
> > >> No, there is a difference in access-control between the two designs.
> > >>
> > >> In the two header design:
> > >> 1) An XHR GET of the XBL file data by example.org *is* allowed.
> > >> 2) An <xbl> import of the XBL data by example.org triggers a
> rendering error.
> > >
> > > That's a bad design. It would make people think they had secured the
> file
> > > when they had not.
> >
> > The headers explicitly say that a read request from any Origin is
> allowed:
> >
> > Access-Control-Allow-Origin: *
> >
> > The above syntax is the one CORS came up with. How could it be made
> clearer?
>
> By not having two headers, but just having one.
>
>
> > > Security should be consistent across everything.
> >
> > It is. All Origins have read access. The data just renders in a
> > different way depending on if/how it is embedded.
>
> I am not interested in this kind of distinction. I think we should only
> have one distinction -- either an origin can use the data, or it can't.
>
>
> > >> In the one header design:
> > >> 1) An XHR GET of the XBL file data by example.org is *not* allowed.
> > >> 2) An <xbl> import of the XBL data by example.org triggers a
> rendering error.
> > >
> > > That's what I want.
> >
> > What you want, and the mechanism you propose to get it, are at odds.
> > I've described the CSRF-like attack multiple times.
>
> Sure, you can misuse Origin in complicated scenarios to introduce CSRF
> attacks. But XBL2 doesn't have those scenarios, and nor do <video>,
> <img>+<canvas>, and any number of other options. Most XHR2 uses don't
> involve the multiple sites either. We shouldn't make _everything_ far more
> complicated just because there is a way to misuse the feature in a case
> that is itself already complicated.
>
>
> > The access control model you propose doesn't actually work.
>
> It works fine for XBL2, Web Sockets, <video>, <img>+<canvas>, sharing
> data across multiple servers in one environment, etc.
>
>
> > To actually control access to the XBL file data you need to use
> > something like the secret token designs we've discussed.
>
> I'm sorry but it's simply a non-starter to have to use secret tokens for
> embedding XBL resources. That's orders of magnitude more complexity than
> most authors will be able to deal with.
>
> There are no scripts involved in these scenarios. It would simply lead to
> the "secret" tokens being baked into public resources, which would make it
> trivial for them to be forged, which defeats the entire purpose.
>
>
> > >> Under the two header design, everyone has read access to the raw bits
> > >> of the XBL file.
> > >
> > > That's a bad thing.
> >
> > In the scenario you described, everyone *does* have read access to the
> > raw bits.
>
> Only people behind the intranet, or with the right cookies, or with the
> right HTTP authentication, or with the right IP addresses. That's not
> everyone.
>
>
> > In your scenario, we were just trying to discourage bandwidth stealing.
>
> I am trying to do many things. Bandwidth stealing is one. Securing
> semi-public resources is another. Securing resources behind intranets is
> yet another. These are all use cases that CORS makes trivial and which UM
> makes incredibly complicated.
>
>
> Personally the more I discuss this the more convinced I am becoming that
> CORS is the way to go.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>