W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2016

Re: Limiting requests from the internet to the intranet.

From: Justin Schuh <jschuh@google.com>
Date: Mon, 4 Jan 2016 14:16:36 -0800
Message-ID: <CAObUUC_u6jBEYh1RaGdxSwtHOuB7Xn9Qx16DGsrjxgWEbs43Yg@mail.gmail.com>
To: Chris Palmer <palmer@google.com>
Cc: Mike West <mkwst@google.com>, Richard Barnes <rbarnes@mozilla.com>, Erik Nygren <erik+w3@nygren.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>, Brian Smith <brian@briansmith.org>, Ryan Sleevi <sleevi@google.com>, Devdatta Akhawe <dev@dropbox.com>, Anne van Kesteren <annevk@annevk.nl>, lee@asgard.org
On Mon, Jan 4, 2016 at 2:04 PM, Chris Palmer <palmer@google.com> wrote:

> On Mon, Jan 4, 2016 at 1:31 PM, Justin Schuh <jschuh@google.com> wrote:
> I was thinking something more like "https://pebble.com/ wants to access
>>>> resources on your internal network." rather than an origin->origin mapping.
>>>> That seems like the right granularity for the user-side of this kind of
>>>> decision, assuming that the devices themselves have to opt-in as well.
>>> OK that sounds pretty good to me.
>> I don't think this can ever be something that a remote site should be
>> able to request. First off, I don't think we can devise a prompt or chooser
>> that presents a meaningful security distinction to the user (my parents
>> don't have the slightest clue what "resources on your internal network"
>> means). But more importantly, the CORS opt-in is part of how local/private
>> apps convey that they're sufficiently robust to accept this increased
>> exposure from the public Internet. So, if the app can't be updated to send
>> this new CORS header, then it's pretty clear that it hasn't met the
>> bare-minimum safety bar.
> I don't think Mike meant to say that the remote site requests the pop-up,
> per se. Here is what I imagine happening, and what I think (?) Mike meant:
> * public-origin.com tries to make a request to internal-origin.localdomain
> * Browser fires off CORS preflight check to internal-origin.localdomain
> * If the check fails, browser throws error to public-origin.com as normal
> * If the check passes, browser raises dialog to the person
> The dialog names public-origin.com; we can bikeshed whether the dialog
> should name internal-origin.localdomain or just vaguely "resources on your
> internal..."
> Either way, I don't think the spec should call for specific strings/string
> patterns, including requiring naming or not naming the public or the
> internal origin. That's an implementation decision.
> However, if the UA does name the public origin, I don't think it makes
> sense to name a specific non-secure public origin. If the UA says that
> public-origin.com will do the accessing of internal resources, and if
> public-origin.com is well-authenticated, then that statement has some
> meaning. But if public-origin.com is not authenticated (e.g. plaintext
> HTTP), then a good UA should say something to the effect of, "
> http://public-origin.com and whoever can poison DNS or JavaScript or...
> wants to access resources on your internal..."

Ah, I assumed we'd just treat it as a 403.

Because I doubt all UAs would really use such wording — although I think
> they should, because it's honest — I lean toward specifying that only
> secure public origins to even try to access internal stuff. Now, I know
> CORS doesn't currently require HTTPS (even though it should have, to start
> to enforce what it claims), but I don't see why we can't start doing things
> right now that we are inventing new things. It's a new year, we can try new
> things... :)
> Independent of this, I do think browser implementers should provide for
>> legacy and testing bypasses via their own mechanisms. In the case of
>> Chrome's implementation, I'd always intended that this would land with
>> enterprise policy and command line support for manually adding
>> private/local hosts for public access.
> Agreed.
>> I don't see a point in prompting at all (once again, for my parents'
>> sake). If we've gotten to the point of the private/local origin opening the
>> hole, then I think it's safe to just silently let it work. I mean, both
>> sides have already opted in, so do you really think the average user is
>> better qualified to make the decision at this stage?
> Sometimes, yes. As long as the prompts aren't frequent — I am satisfied
> they won't be if they don't even happen until both sides opt in — then they
> are/can be a gesture of respect for the person's control over their stuff..

Do you really think prompting makes sense as a default? Given the exposure
here I'd view it as analogous to approving cookies or allowing Javascript
to run. Although, I suppose your counter would be that those are far more
ubiquitous (and were they not we'd prompt). Even so, it feels unnecessary
and potentially confusing to me.

That stated, I think more narrow scoping is a good reason to have the
>> private/local host explicitly specify an allow list for public origins
>> (although they can manage that logic on their own using the origin header).
> Agreed.
Received on Tuesday, 5 January 2016 09:27:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:53 UTC