Re: [UMP] Server opt-in

On Tue, Jan 12, 2010 at 4:24 PM, Mark S. Miller <erights@google.com> wrote:
> Hi Adam, I don't understand this at all.

Is the use case unclear?

On Tue, Jan 12, 2010 at 2:44 PM, Adam Barth <w3c@adambarth.com> wrote:
> 1) I'm a server operator and I want to provide a resource to other web sites.
> 2) I've been reading public-webapps and I'm concerned about the
> ambient authority in CORS.
>
> How can I share my resource with other web sites and enjoy the
> security benefits of UMP?

Specifically, I'd like to provide this resource to web sites without
worrying about leaking user-specific state to malicious web sites.

> First, as the draft UMP already
> says, were it not for the need to be compatible with currently deployed
> browser behaviors, UMP would prefer a short header "U:" anyway, rather than
> the unfortunately long "Access-Control-Allow-Origin:*" in
> an incompressible position.

Naming concerns aside, as a sever operator, I would like to opt into
UMP alone (and ignore CORS entirely).  When I include
"Allow-Uniform-Messages: level-1" in a response header, I can be
assured that I'm not leaking user-specific information to other web
sites because UMP has helpfully removed all the ambient authority that
might have confused me.

By contrast, if the UMP protocol forces me to use
"Access-Control-Allow-Origin:*", then an evil web site will just use
the more powerful CORS protocol and trick my into revealing
confidential information.

> Second, we are using the same header because it is the means, under CORS,
> XDR, and UMP, for the server to opt-out of same-origin protections.

I'd rather focus on addressing use cases than on semantics.  Do you
think my use case is not worth addressing?

> The
> server cannot force the client to not provide ambient authority information
> in any case.

There are three parties involved:

1) The honest web server
2) The honest user with a conformant browser
3) A malicious web site that the user is visiting

The malicious web site is constrained by the honest browser to either
the CORS or UMP protocol.  If the server can opt into the UMP protocol
(to the exclusion of CORS), the server can enjoy the security benefits
of UMP (no confusing ambient authority).  If the server is required to
opt into *both* UMP and CORS at the same time, the attacker can opt to
use CORS and potentially confuse the server.

> The most it can do is ignore such information. It is up to the
> client not to provide such information. It is the job of the standard to
> require the client not to provide it, and to inform server-side authors not
> to expect it.

Right, but we're working in a threat model where ambient authority is
confusing to servers can causes them to have vulnerabilities.  If the
server is smart enough to understand the dangers of ambient authority,
then we don't need UMP.  CORS would be sufficient.

On Tue, Jan 12, 2010 at 4:56 PM, Tyler Close <tyler.close@gmail.com> wrote:
> UMP supports confidentiality where client and server desire
> confidentiality.

My question, then, is how can a server enjoy the confidentiality
benefits of UMP without paying the security costs of CORS?  As
currently specced, a server needs to take all the CORS risks in order
to use UMP.  That seems unnecessary.

Adam

Received on Wednesday, 13 January 2010 01:35:37 UTC