W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2012

Re: Why the restriction on unauthenticated GET in CORS?

From: Cameron Jones <cmhjones@gmail.com>
Date: Thu, 19 Jul 2012 15:45:43 +0100
Message-ID: <CALGrgevLoUS7mtd6-PYotM5PEsE2_YfQjVY44mE25VtDwtu00g@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, Henry Story <henry.story@bblfish.net>, Ian Hickson <ian@hixie.ch>, public-webapps <public-webapps@w3.org>, public-webappsec@w3.org
On Thu, Jul 19, 2012 at 3:06 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> On Thu, Jul 19, 2012 at 6:54 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> On Thu, Jul 19, 2012 at 2:43 PM, Henry Story <henry.story@bblfish.net> wrote:
>>> If a mechanism can be found to apply restrictions for private IP ranges then that
>>> should be used in preference to forcing the rest of the web to implement CORS
>>> restrictions on public data. And indeed the firewall servers use private ip ranges,
>>> which do in fact make a good distinguisher for public and non public space.
>>
>> It's not just private servers (there's no guarantee those only use
>> private IP ranges either). It's also IP-based authentication to
>> private resources as e.g. W3C has used for some time.
>
> Moreover, some companies have public IP ranges that are
> firewall blocked. It's not in general possible for the browser
> to distinguish publicly accessible IP addresses from non-publicly
> accessible IP addresses.

Yes it is impossible for a browser to detect intranet configurations.

The problem i have is that public providers are being forced to
changed their configurations over internal company networks changing
theirs.

Company IT departments have far more technical skills, and the ability
to perform the changes, than public publishers who may not even be
able to add CORS headers if they wanted to.

>
> More generally, CORS is designed to replicate the restrictions that non-CORS
> already imposes on browsers. Currently, browsers prevent JS from obtaining
> the result of this kind of cross-origin GET, thus CORS retains this restriction.
> This is consistent with the general policy of not adding new features to
> browsers that would break people's existing security models, no matter
> how broken one might regard those models as being.
>

Aside form the intranet public IP concern, isn't this due to the
ambient authority applied to cross-origin GET requests? This turns
otherwise public information into a potentially private resource.

Removing all user-identifiable information from a request would
alleviate this restriction being necessary and not break anyone's
security policy (without considering the public-IP behind a firewall
scenario).


> I believe the WG already has consensus on this point.
>
> -Ekr

Thank-you for the response in light of the existing consensus.
Potential new information, even if not new, being addressed aids
understanding and can assist in further adoption and advocacy.

Thanks,
Cameron Jones
Received on Thursday, 19 July 2012 14:46:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 July 2012 14:46:25 GMT