W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: [UMP] Proxy-Authorization

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 11 Jan 2010 17:06:30 -0800
Message-ID: <7789133a1001111706t50315e4ey3d70751d00be8907@mail.gmail.com>
To: Tyler Close <tyler.close@gmail.com>
Cc: public-webapps <public-webapps@w3.org>
On Mon, Jan 11, 2010 at 12:40 PM, Tyler Close <tyler.close@gmail.com> wrote:
> On Sun, Jan 10, 2010 at 2:25 PM, Adam Barth <w3c@adambarth.com> wrote:
>> More abstractly, why aren't we worrying about P misbehaving based on
>> the ambient authority in R (i.e., the Proxy-Authentication
>> information)?  Why do the security considerations for the
>> Proxy-Authorization header differ from the security considerations for
>> the Authorization header?
>
> The resource host decides whether or not to accept a request, what
> side-effects are caused, and what information is put in the response.
> We want to prevent ambient authority from having an effect on these
> decisions by the resource host.

I'm not sure why we're concerned about misuses of ambient authority by
the resource host but not by the proxy.  If we can trust one to
operate correctly, why can't we trust the other?

> The proxy is presumably semantically
> transparent and so has no impact on these decisions by the resource
> host. For https: resources, this transparency is cryptographically
> enforced by the SSL protocol, which tunnels the connection through the
> proxy.

This seems like a shaky assumption.  For example, imagine a private
network that allows VPN access via an authenticating proxy.  Now, the
ambient authority provided by Proxy-Authentication embues the attacker
with the ability to issue UMP requests inside the VPN.

It just seems like the reason for preferring UMP over CORS is that
we're worried that ambient authority will lead to security
vulnerabilities.  If that's really a problem, we should remove all
ambient authority.

Adam
Received on Tuesday, 12 January 2010 01:07:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:36 GMT