- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 23 Feb 2015 11:42:34 -0800
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Henri Sivonen <hsivonen@hsivonen.fi>, Brad Hill <hillbrad@gmail.com>, WebAppSec WG <public-webappsec@w3.org>, WebApps WG <public-webapps@w3.org>, Monsur Hossain <monsur@gmail.com>, Dale Harvey <dale@arandomurl.com>
On Mon, Feb 23, 2015 at 11:06 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Mon, Feb 23, 2015 at 7:55 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> A lot websites accidentally enabled cross-origin requests with >> cookies. Not realizing that that enabled attackers to make requests >> that had side-effects as well as read personal user data without user >> permission. >> >> In short, it was very easy to misconfigure a server, and people did. >> >> This is why I would feel dramatically more comfortable if we only >> enabled server-wide opt-in for credential-less requests. Those are >> many orders of magnitude easier to make secure. > > Why is that not served by requiring an additional header that > explicitly opts into that case? I don't think an extra header is that much harder to deploy than crosssite.xml is. I.e. I don't see strong reasons to think that people won't misconfigure. > That combined with requiring to list > the explicit origin has worked well for CORS so far. This could potentially help. I don't remember the details of how/why people screwed up with crosssite.xml. But if the problem was that people hosted multiple services on the same server and only thought of one of them when writing a policy, then this won't really help very much. Do we have any data on how common it is for people to use CORS with credentials? My impression is that it's far less common than CORS without credentials. If that's the case then I think we'd get most of the functionality, with essentially none of the risk, by only allowing server-wide cookie-less preflights. But data would help for sure. / Jonas
Received on Monday, 23 February 2015 19:43:32 UTC