- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 12 Jan 2010 17:34:41 -0800
- To: "Mark S. Miller" <erights@google.com>
- Cc: public-webapps <public-webapps@w3.org>, Tyler Close <tyler.close@gmail.com>
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