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: Mon, 4 Jan 2016 12:29:02 -0500
Message-ID: <CAOAcki_9eNDOig=MMRirYeTzkwJ-XHhxz7KK_4rbAriEc4ZA2g@mail.gmail.com>
To: Erik Nygren <erik+w3@nygren.org>
Cc: Mike West <mkwst@google.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
Mike, I like this idea of solving this with a CORS-like preflight.  If we
do this as well as HSTS preflight, we'll need a new spec to consolidate all
the security preflights :)

I agree with Erik that the general problem of defining "intranet" addresses
is a little tricky.  However, the loopback / localhost problem is more
clearly defined.  The IPv4 range and the IPv6 address ::1 are
both clearly reserved for talking to the local host, which obviously has
special security considerations.  You might also extend this to the link
local ranges and fe80::/16.

Given this fiddliness, it seems like we might not be able to get by with a
binary as the document suggests.  But at the same time, it would be
undesirable to turn the browser into a general-purpose IP-filtering
firewall!  Maybe the thing to do is to define a few categories of address
("global", "private", "loopback", "link-local"), send a preflight for any
of them, and let the server say which it will allow?

On Mon, Jan 4, 2016 at 11:29 AM, Erik Nygren <erik+w3@nygren.org> wrote:

> While this is trying to address a real concern, we should be very careful
> not to convey special meaning to IP address ranges at the application
> layer.  In particular, IPv6 (now past 10% globally per Google and at around
> 20% in the US) tries to enable global Internet addressing without private
> NAT bubbles.  For example, residential and enterprise IPv6 users will have
> devices behind their firewall numbered with public addresses from a
> delegated prefix (and NOT ULA or link-local addresses).  There's been a
> strong desire by groups working on IPv6 roll-out to try and encourage
> mechanisms other than NAT-based hacks for providing security goals.  As
> another example, RFC 6598 added a new IPv4 RFC1918-like shared transition
> space which is likely to be used in similar situations.
> It may make sense for there to be a way for a "protected address space"
> policy to be configured more dynamically.  (I'll avoid particular
> suggestions such as DHCP at this point since each has its own challenges.)
>        Erik
> On Mon, Jan 4, 2016 at 8:10 AM, Mike West <mkwst@google.com> wrote:
>> Happy new year, WebAppSec! This seems like a lovely time to rekindle the
>> fire under the public/private origin restriction that we removed from Mixed
>> Content way back in 2014 (
>> http://www.w3.org/TR/2014/WD-mixed-content-20140722/#private-origin).
>> I've put together a kinder, gentler take on hardening the user agent
>> against the kinds of attacks that such requests enable:
>> https://mikewest.github.io/cors-rfc1918/. It's pretty rough, as I've
>> only poked at it sporadically over the holidays, but I think there's enough
>> there to get a conversation going.
>> In a nutshell, the proposal is to require a CORS-preflight request for
>> requests initiated from the public internet which target private IP space.
>> This preflight requires an opt-in on the part of the intranet server via a
>> new CORS header, but doesn't block the requests entirely (which was a
>> failing of the initial proposal). I imagine this server-side opt-in being
>> combined in some intelligent way with a user-side opt-in (Presto-style
>> interstitial? permission request?), but I haven't explored anything in that
>> direction.
>> CCing a few folks who've commented on the topic in the past; I imagine
>> you'll have opinions. :)
>> -mike
Received on Monday, 4 January 2016 17:29:33 UTC

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