- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 20 Feb 2015 12:38:21 -0800
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WebAppSec WG <public-webappsec@w3.org>, WebApps WG <public-webapps@w3.org>
On Fri, Feb 20, 2015 at 1:05 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Thu, Feb 19, 2015 at 9:22 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> Would this be allowed for both requests with credentials and requests >> without credentials? The security implications of the two are very >> different. > > Yes, but the latter requires the Access-Control-Allow-Credentials > header to be included in the response. Ok. I'm not really sure how one would go about securing a whole server to make sure that it's safe for requests with credentials. But I'll leave this decision to others. > An alternative is that we attempt to introduce > Access-Control-Policy-Path again from 2008. The problems you raised > https://lists.w3.org/Archives/Public/public-appformats/2008May/0037.html > seem surmountable. URL parsing is defined in more detail these days > and we could simply ban URLs containing escaped \ and /. I do remember that another issue that came up back then was that servers would treat more than just '\', or the escaped version thereof, as a /. But also any character whose low-byte was equal to the ascii code for '\' or '/'. I.e. the server would just cut the high-byte when doing some internal 2byte-string to 1byte-string conversion. Potentially this conversion is affected by what character encodings the server is configured for too, but i'm less sure about that. These weren't small servers either, but some of the most popular ones at the time. I don't know if this problem has gone away over time though. I.e. if more updated versions don't exhibit this problem. / Jonas
Received on Friday, 20 February 2015 20:39:19 UTC