- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 22 Jun 2009 14:01:41 -0700
- To: Tyler Close <tyler.close@gmail.com>
- Cc: Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@opera.com>, Mark Nottingham <mnot@mnot.net>, public-webapps@w3.org
On Mon, Jun 22, 2009 at 1:16 PM, Tyler Close<tyler.close@gmail.com> wrote: > On Mon, Jun 22, 2009 at 12:33 PM, Adam Barth<w3c@adambarth.com> wrote: >> 1) We can't strip all the credential information from cross-origin requests. >> 2) There's a large amount of value is supporting all the normal >> credentials associated with HTTP requests. >> 3) Given (1), we have to deal with the credential issue. Given (2), >> we get a large benefit from from supporting all kinds of credentials. >> 4) Given (3), some folks have made a judgement call that value of >> supporting credentials is worth the complexity. > > Perhaps that is the reasoning of the authors, I don't know. Ian > Hickson's email seemed to suggest that IP-based authentication was the > primary reason to not consider the simpler approach I outlined. In > either case, we know that the value of (2) is illusory since CSRF > vulnerabilities prevent its use (unless all the sites in the scenario > are trusted). Why is this the case? Suppose I have a weather widget that wants to remember for which ZIP codes I want to see the weather. It seems easiest to store the zip code information in a cookie and fetch the weather report via CORS. Alternatively, the weather widget might want to let me pick a personalized theme for the widget and store the choice on its server (via a POST request). Somehow, I don't think the weather widget cares about CSRF. > For (1), I think it's worth investigating exactly what > sites rely on. For example, if sites are only relying on IP-based > authentication to ensure a response is delivered to that IP address, > then we're in good shape, since we can easily implement this by > checking for the absence of a cross-domain enabled header. I don't see why IP authenticated services would only care about confidentiality. They might well care about integrity also. For example, suppose my home router exposed a RESTful interface for configuring port forwarding. On reasonable design is to accept PUT requests to add new forwarding configuration. If you open the world to "credential-less" GuestXHR, then any random web site can add port forwarding configurations to my router by hijacking my connectivity credential. > So I just did some poking around on the ACM digital library site (I > believe my company also has a site license). Only GET requests are > made when fetching a paper, so this use-case is not relevant to this > discussion. CORS also allows GET requests to be sent without > restriction. Perhaps you have an all-you-can-eat subscription? In any case, I don't see why they wouldn't use POST requests for other features. Adam
Received on Monday, 22 June 2009 21:02:33 UTC