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

Re: Limiting requests from the internet to the intranet.

From: Erik Nygren <erik+w3@nygren.org>
Date: Mon, 4 Jan 2016 11:29:27 -0500
Message-ID: <CAKC-DJg=smRsKjC6tc_agFetWJ9Q1vONhCrCgzcnM_7rkehcmw@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: "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
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.)


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 16:30:01 UTC

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