W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: CORS performance proposal

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 20 Feb 2015 12:38:21 -0800
Message-ID: <CA+c2ei8N5UggBeVfZzNUFsLnZvDf-1Cfc6+3GD-VdpiWyiaNuA@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC