Re: Limiting requests from the internet to the intranet.

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 127.0.0.0/8 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 169.254.0.0/16 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
>>
>
>