Re: Limiting requests from the internet to the intranet.

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.
>