- From: Tyler Close <tyler.close@gmail.com>
- Date: Tue, 12 Jan 2010 15:10:21 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: public-webapps <public-webapps@w3.org>
On Tue, Jan 12, 2010 at 2:57 PM, Adam Barth <w3c@adambarth.com> wrote: > On Tue, Jan 12, 2010 at 2:47 PM, Tyler Close <tyler.close@gmail.com> wrote: >> On Tue, Jan 12, 2010 at 2:44 PM, Adam Barth <w3c@adambarth.com> wrote: >>> Let my phrase my question another way. Suppose the following situation: >>> >>> 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? >> >> Follow the advice given in the "Security Considerations" section of >> the UMP spec: >> >> http://dev.w3.org/2006/waf/UMP/#security > > As a server operator, why can't I follow that advice with CORS? You can. > Nothing there seems specific to UMP. UMP is more restrictive on the server than is CORS. UMP doesn't make the client's ambient authority visible to the server. > I don't understand how UMP is helping server operators deal with the > risks of ambient authority. When a server operator makes a resource > available via UMP, they're also making it available to CORS with it's > attendant security model. UMP is helping server operators define APIs that enable their clients to defend themselves against CSRF-like vulnerabilities. A CSRF-like attack takes place on the client-side, not the server-side. The server's behavior needs to be restricted in a way that enables the client to communicate its wishes, while defending itself against CSRF. In particular, the client must be able to make a request without applying its credentials to the request, so the server must handle the request without demanding credentials be provided. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Tuesday, 12 January 2010 23:10:54 UTC