On Mon, Jan 4, 2016 at 6:29 PM, 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 :)
>
For clarity, this isn't a "CORS-like" preflight. It is the CORS preflight.
That is, the proposal is to a) trigger the CORS preflight for external
requests, just as we would for "unsafe" cross-origin requests in the status
quo, and b) to explicitly opt into public/private sharing with a new header
on the CORS response.
That is, this proposal won't cause an additional preflight on top of the
CORS preflight for the case in which a public site requests something from
a private site that would trigger the CORS preflight in the status quo. It
just hardens that request's validation steps.
I agree with Erik that the general problem of defining "intranet" addresses
> is a little tricky.
>
I appreciate both of your feedback. I should note that I know only enough
about IPv6 to be dangerous, so I very much welcome your collective
expertise. Which RFCs/threads ought I be skimming?
Also, given that the IPv4 landscape is defined in terms of IP ranges, for
better or worse, I hope we'll be able to make progress on that front while
working out the right thing to do for the future.
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.
>
Yup. I plan to extend the document to include loopback / link-local ranges
when I get around to adding the "local" category (that's
https://mikewest.github.io/cors-rfc1918/#issue-69ad818f). I'm happy to hear
that those ranges, at least, are clearly defined. :)
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!
>
But a special-purpose filtering tool seems reasonable, doesn't it? I don't
want to give the internet access to my router, or to give it the ability to
map my local network. The user agent ought to help out with those goals,
shouldn't it?
> 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?
>
I'm not following. Can you sketch this out in a bit more detail?
-mike