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

Re: Limiting requests from the internet to the intranet.

From: Mike West <mkwst@google.com>
Date: Fri, 8 Jan 2016 14:10:28 +0100
Message-ID: <CAKXHy=dGQtOq3QZb1Oi97yEDe5Gk2RC8c9MzXTqFwLddN0V4kA@mail.gmail.com>
To: Erik Nygren <erik+w3@nygren.org>
Cc: "Nottingham, Mark" <mnotting@akamai.com>, Richard Barnes <rbarnes@mozilla.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 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?

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

Received on Friday, 8 January 2016 13:11:19 UTC

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