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

Re: Limiting requests from the internet to the intranet.

From: Richard Barnes <rbarnes@mozilla.com>
Date: Fri, 8 Jan 2016 10:14:25 -0800
Message-ID: <CAOAcki_tFs6YMvRr8zwvPDzuLEjaRYm6t9e+SkZ1wVgzBFPgkw@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Erik Nygren <erik+w3@nygren.org>, "Nottingham, Mark" <mnotting@akamai.com>, "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>, Justin Schuh <jschuh@google.com>, Devdatta Akhawe <dev@dropbox.com>, Anne van Kesteren <annevk@annevk.nl>, Chris Palmer <palmer@google.com>, "lee@asgard.org" <lee@asgard.org>
On Fri, Jan 8, 2016 at 5:10 AM, Mike West <mkwst@google.com> wrote:

> On Tue, Jan 5, 2016 at 12:07 AM, Erik Nygren <erik+w3@nygren.org> wrote:
>
>> MDNS names (such as "example.local") also provide a way to get at these
>> resources without needing to probing adjacent address space since they may
>> resolve to public IPv4 or public IPv6 addresses.  One way of tackling those
>> could be to treat ".local" names as all being private regardless of what
>> IPs they resolve to.
>>
>
> Adding `.local` makes sense to me, thanks!
>
>
>> I agree that there are some cases like localhost in particular where this
>> is straight-forward (and especially valuable as part of a "(http,localhost)
>> as secure origins for sub-resources but requiring CORS" story).
>>
>
> Right. I think I noted in the doc that enforcing these limitations would
> make me happier about not blocking `http://[loopback]` as mixed content.
> I'm not happy at all about doing that in the status quo.
>
> On Mon, Jan 4, 2016 at 5:40 PM, Nottingham, Mark <mnotting@akamai.com>
>> wrote:
>>
>>> Are we trying to defend against the case where an attacker looks at the
>>> global IPv6 address of the UA and then crafts the attack to probe adjacent
>>> space (i.e., within the delegated prefix)?
>>>
>>
> I would like to do this. It sounds like y'all are telling me that that's
> hard to do in a well-defined way.
>
>
>> Or are we just trying to provide (imperfect) defence in depth against
>>> attacks against sloppy local services that assume being behind NAT means
>>> they're safe?
>>>
>>
> Certainly this.
>
>
>> I think Richard is on a pretty good path -- expose the primitives that we
>>> have reasonably easy access to, and figure out reasonable default
>>> behaviours for each.
>>>
>>
> I still don't follow Richard's proposal. What do you think he's
> suggesting? :)
>

I would also be interested to know what Erik thought I was suggesting, but
let me try to explain what I meant:

- Spec defines a few categories of address space / source ("global",
"private", "loopback", "link-local", "dot-local")
- A CORS header like Access-Control-Allow-Network can allow access from any
of these tokens

I'm not sure I really think this is the best idea, but in any case, wanted
to be clearer.

--Richard



> P.S. Maybe this is an opportunity to reopen a discussion of OPTIONS-free
>>> CORS; some of these things get quite chatty.
>>>
>>
> Certainly worth exploring. I think you have a concrete proposal floating
> around somewhere? Might be worth a separate thread.
>
> -mike
>
Received on Friday, 8 January 2016 18:14:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:17 UTC