Re: Limiting requests from the internet to the intranet.

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.

In the IPv6 world you can generally replace "NAT" with "Firewall".
Scanning is still fairly straight-forward to find devices  (eg, if you know
a printer manufacturer with a vulnerability and the printer isn't using
privacy addressing, you
know what EUI-64 host-id range to scan within the delegated prefix of the
UA.
It is bigger, but certainly doable in javascript.)

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

      Erik


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