Re: Limiting requests from the internet to the intranet.

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)?

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?

The former seems like a pretty high bar, because it would require the browser to have a detailed (and correct) view of local network architecture.

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.

Cheers,

P.S. Maybe this is an opportunity to reopen a discussion of OPTIONS-free CORS; some of these things get quite chatty.


> On 5 Jan 2016, at 4:29 am, Richard Barnes <rbarnes@mozilla.com> wrote:
> 
> 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
> 
> 

--
Mark Nottingham    mnot@akamai.com    https://www.mnot.net/

Received on Monday, 4 January 2016 22:41:14 UTC