Intent to Implement: Secure context restriction for external requests.
630 views
Skip to first unread message
Mike West
Jul 23, 2019, 5:38:49 AM7/23/19
to blink-dev
mk...@chromium.org
https://wicg.github.io/cors-rfc1918/#integration-fetch
Specification: https://wicg.github.io/cors-rfc1918/
"External requests" are those initiated from a public network, targeting a private network (e.g. internet -> intranet, or intranet -> loopback). These requests may only be initiated from a secure context.
Servers running inside local networks, or on a users' device, expose powerful capabilities to the web in ways that can be quite dangerous. CORS-RFC1918 proposes a set of changes that can limit the impact of requests to these servers by ensuring that the servers are opting-into any communication with external entities.
In order for this opt-in to have any meaning, the servers need to be able to ensure that the client origin is authenticated. To that end, only secure contexts are empowered to make external requests.
This change is separable from the rest of CORS-RFC1918, and we can make it now, before the rest of the larger feature is ready.
~0.05% of page views are currently loading at least one resource from a loopback address, and this change would affect them in one way or another: https://www.chromestatus.com/metrics/feature/timeline/popularity/1653. We'll need to do a little more digging to figure out exactly what will break and how much user-facing impact there would be.
We will almost certainly need an enterprise opt-out of some sort (which is unfortunate, as enterprises are exactly the sort of things that have large local networks full of interesting resources!).
Firefox: Mixed public signals (https://github.com/mozilla/standards-positions/issues/143, https://bugzilla.mozilla.org/show_bug.cgi?id=1481298)
Edge: No public signals
Safari: No public signals
Web developers: Negative (https://bugs.webkit.org/show_bug.cgi?id=171934)
Developers running local servers generally want those servers to keep running without alteration. The conversation on a tangentially-related WebKit bug is representative.
Developers of non-secure sites that rely upon local servers will need to upgrade to HTTPS. This might cause some complications, as mixed-content checks will begin to apply. Chrome carves out HTTP access to loopback (as perhttps://w3c.github.io/webappsec-secure-contexts/#localhost), which is a release valve for folks who don't want to go through the effort of securely-distributing certs for local servers.
This change should be security-positive.
When blocking a request due to a secure-context restriction, we'll add a helpful message to the console.
Yes
No
This will be quite difficult to test in WPT, because WPT does not directly support loopback addresses. See https://github.com/web-platform-tests/wpt/pull/5304.
https://chromestatus.com/feature/5436853517811712Thanks!
-mike
Eric Lawrence
Jul 23, 2019, 11:17:13 AM7/23/19
to blink-dev
Interesting.
Similarly, what happens in the event that a resource was available in the cache and would not otherwise have resulted in a network request?
What happens in the event of same-origin HTTP requests whereby the target origin is available (either simultaneously or at different times or on different networks) at both private and public IP addresses? (We once found that the Outlook Web Access single page application was broken when users took their laptops home, because the target IP and thus security zone changed as they moved their device between networks). Stated another way, should "External request" explicitly exclude "Same origin" requests? Or is the hope to use this mechanism to help mitigate DNS rebinding attacks?
Mike West
Jul 23, 2019, 11:52:14 AM7/23/19
to Eric Lawrence, blink-dev
On Tue, Jul 23, 2019 at 5:17 PM Eric Lawrence <elaw...@chromium.org> wrote:
What happens in the event that a user is behind a proxy server and thus would not otherwise be performing local DNS resolutions?
To start with, I think we'll punt on proxies. I'd welcome insight from folks that have a better understanding of the kinds of data we can trust that we'd get back from a proxy, but I don't think it'll be possible for us to do an a priori check as we can when we connect the socket ourselves.
Similarly, what happens in the event that a resource was available in the cache and would not otherwise have resulted in a network request?
#4 in https://wicg.github.io/cors-rfc1918/#integration-fetch waves its hands at this problem, and suggests that the network cache would store the request type, and use that when determining whether we match. I think we'll need to work out together whether that's feasible.
What happens in the event of same-origin HTTP requests whereby the target origin is available (either simultaneously or at different times or on different networks) at both private and public IP addresses? (We once found that the Outlook Web Access single page application was broken when users took their laptops home, because the target IP and thus security zone changed as they moved their device between networks). Stated another way, should "External request" explicitly exclude "Same origin" requests? Or is the hope to use this mechanism to help mitigate DNS rebinding attacks?
The draft does aim to poke at rebinding attacks: directly via the checks we'd do on each outgoing request, regardless of hostname; and indirectly, by requiring HTTPS (as in this intent), which gives internal servers a modicum of confidence that the CORS check we'll eventually force is referring to an authenticated server. This latter property means that Outlook could accept CORS preflights from its own origin, as that would be difficult indeed for an attacker to forge.
It would, however, require the developer to understand that users' network movement can cause preflights, which will absolutely cause some havoc at some point in the future. Note again that _this_ intent is smaller, and simply requires that Outlook be securely hosted in order to make external requests at all. That should be simple enough to satisfy.
-mike
On Tuesday, July 23, 2019 at 4:38:49 AM UTC-5, Mike West wrote:mk...@chromium.org https://wicg.github.io/cors-rfc1918/#integration-fetch Specification: https://wicg.github.io/cors-rfc1918/ "External requests" are those initiated from a public network, targeting a private network (e.g. internet -> intranet, or intranet -> loopback). These requests may only be initiated from a secure context. Servers running inside local networks, or on a users' device, expose powerful capabilities to the web in ways that can be quite dangerous. CORS-RFC1918 proposes a set of changes that can limit the impact of requests to these servers by ensuring that the servers are opting-into any communication with external entities. In order for this opt-in to have any meaning, the servers need to be able to ensure that the client origin is authenticated. To that end, only secure contexts are empowered to make external requests. This change is separable from the rest of CORS-RFC1918, and we can make it now, before the rest of the larger feature is ready.~0.05% of page views are currently loading at least one resource from a loopback address, and this change would affect them in one way or another: https://www.chromestatus.com/metrics/feature/timeline/popularity/1653. We'll need to do a little more digging to figure out exactly what will break and how much user-facing impact there would be. We will almost certainly need an enterprise opt-out of some sort (which is unfortunate, as enterprises are exactly the sort of things that have large local networks full of interesting resources!). Firefox: Mixed public signals (https://github.com/mozilla/standards-positions/issues/143, https://bugzilla.mozilla.org/show_bug.cgi?id=1481298) Edge: No public signals Safari: No public signals Web developers: Negative (https://bugs.webkit.org/show_bug.cgi?id=171934) Developers running local servers generally want those servers to keep running without alteration. The conversation on a tangentially-related WebKit bug is representative. Developers of non-secure sites that rely upon local servers will need to upgrade to HTTPS. This might cause some complications, as mixed-content checks will begin to apply. Chrome carves out HTTP access to loopback (as perhttps://w3c.github.io/webappsec-secure-contexts/#localhost), which is a release valve for folks who don't want to go through the effort of securely-distributing certs for local servers. This change should be security-positive.When blocking a request due to a secure-context restriction, we'll add a helpful message to the console. Yes No This will be quite difficult to test in WPT, because WPT does not directly support loopback addresses. See https://github.com/web-platform-tests/wpt/pull/5304. https://chromestatus.com/feature/5436853517811712Thanks!-mike
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6bd84a0b-8309-43fb-bc54-9d55e6581740%40chromium.org.
David Benjamin
Jul 24, 2019, 10:56:39 AM7/24/19
to Mike West, Eric Lawrence, blink-dev
On Tue, Jul 23, 2019 at 11:52 AM Mike West <mk...@chromium.org> wrote:
On Tue, Jul 23, 2019 at 5:17 PM Eric Lawrence <elaw...@chromium.org> wrote:What happens in the event of same-origin HTTP requests whereby the target origin is available (either simultaneously or at different times or on different networks) at both private and public IP addresses? (We once found that the Outlook Web Access single page application was broken when users took their laptops home, because the target IP and thus security zone changed as they moved their device between networks). Stated another way, should "External request" explicitly exclude "Same origin" requests? Or is the hope to use this mechanism to help mitigate DNS rebinding attacks?The draft does aim to poke at rebinding attacks: directly via the checks we'd do on each outgoing request, regardless of hostname; and indirectly, by requiring HTTPS (as in this intent), which gives internal servers a modicum of confidence that the CORS check we'll eventually force is referring to an authenticated server. This latter property means that Outlook could accept CORS preflights from its own origin, as that would be difficult indeed for an attacker to forge.It would, however, require the developer to understand that users' network movement can cause preflights, which will absolutely cause some havoc at some point in the future. Note again that _this_ intent is smaller, and simply requires that Outlook be securely hosted in order to make external requests at all. That should be simple enough to satisfy.
If https://example.com(external IP) tries to make a request to https://example.com(internal IP), it may be reasonable to not do a CORS-RFC1918 preflight at all. We've already got a good reason to believe it's talking to itself here by way of TLS.
That, however, doesn't help with https://service1.example.com(external IP) trying to talk to https://service2.example.com(internal IP) where the two services are meant to interact and the internal vs. external IP business is just a consequence of moving between networks that see staging and non-staging instances while a page is open. How to distinguish that scenario from it trying to exploit a CSRF bug on https://intranet-site.example(internal IP) is unclear. Perhaps asking sites with such a development setup to deploy CORS headers or have developers reload the page is reasonable?
Come to think of it, in scenarios where the destination origin is some buggy router or local server, the destination is unlikely to be using HTTPS to begin with. With this change, almost all such accesses are mixed content. We already block active mixed content. We don't block passive mixed content, but perhaps step 2 here should be blocking cross-IP-space passive mixed content. That then leaves only HTTPS intranet sites and localhost that see the actual CORS-RFC1918 preflights.
----On Tuesday, July 23, 2019 at 4:38:49 AM UTC-5, Mike West wrote:mk...@chromium.org https://wicg.github.io/cors-rfc1918/#integration-fetch Specification: https://wicg.github.io/cors-rfc1918/ "External requests" are those initiated from a public network, targeting a private network (e.g. internet -> intranet, or intranet -> loopback). These requests may only be initiated from a secure context. Servers running inside local networks, or on a users' device, expose powerful capabilities to the web in ways that can be quite dangerous. CORS-RFC1918 proposes a set of changes that can limit the impact of requests to these servers by ensuring that the servers are opting-into any communication with external entities. In order for this opt-in to have any meaning, the servers need to be able to ensure that the client origin is authenticated. To that end, only secure contexts are empowered to make external requests. This change is separable from the rest of CORS-RFC1918, and we can make it now, before the rest of the larger feature is ready.~0.05% of page views are currently loading at least one resource from a loopback address, and this change would affect them in one way or another: https://www.chromestatus.com/metrics/feature/timeline/popularity/1653. We'll need to do a little more digging to figure out exactly what will break and how much user-facing impact there would be. We will almost certainly need an enterprise opt-out of some sort (which is unfortunate, as enterprises are exactly the sort of things that have large local networks full of interesting resources!). Firefox: Mixed public signals (https://github.com/mozilla/standards-positions/issues/143, https://bugzilla.mozilla.org/show_bug.cgi?id=1481298) Edge: No public signals Safari: No public signals Web developers: Negative (https://bugs.webkit.org/show_bug.cgi?id=171934) Developers running local servers generally want those servers to keep running without alteration. The conversation on a tangentially-related WebKit bug is representative. Developers of non-secure sites that rely upon local servers will need to upgrade to HTTPS. This might cause some complications, as mixed-content checks will begin to apply. Chrome carves out HTTP access to loopback (as perhttps://w3c.github.io/webappsec-secure-contexts/#localhost), which is a release valve for folks who don't want to go through the effort of securely-distributing certs for local servers. This change should be security-positive.When blocking a request due to a secure-context restriction, we'll add a helpful message to the console. Yes No This will be quite difficult to test in WPT, because WPT does not directly support loopback addresses. See https://github.com/web-platform-tests/wpt/pull/5304. https://chromestatus.com/feature/5436853517811712Thanks!-mike
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6bd84a0b-8309-43fb-bc54-9d55e6581740%40chromium.org.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dcf4hom_%3DHD034-Wv63yLPMs%2BgRfnc5k4wvatHDbSE6HA%40mail.gmail.com.
nyg...@gmail.com
Jul 24, 2019, 11:09:06 AM7/24/19
to blink-dev
There is some compatibility risk if Safari/WebKit continues to not treat localhost as a secure context:
Otherwise contradictory contexts will be needed to access localhost resources without triggering mixed-content?
ie, Safari/WebKit will require a non-secure site to access localhost resources without mixed content while Chrome will require a secure site to do so.
(Encouraging Safari/WebKit to implement localhost-as-secure-context, perhaps with secure context and CORS restrictions seems like one path to get consistency and interoperability?)
David Benjamin
Jul 24, 2019, 11:24:01 AM7/24/19
to nyg...@gmail.com, blink-dev
Allowing external IPs to access localhost servers without even a TLS-authenticated origin to bind the CORS-RFC1918 preflight to seems thoroughly undesirable. A localhost server which says external requests from http://example.com are allowed is just saying the entire internet can access it. Whereas external requests from https://example.com is actually a meaningful arrangement.
Erik Anderson
Jul 24, 2019, 4:43:53 PM7/24/19
to blink-dev, nyg...@gmail.com
This is a great direction to start heading down.
The edgehtml-based version of Microsoft Edge leverages Windows' AppContainer network isolation to prevent internet-hosted pages from accessing intranet resources, but we ended up having to allow loopback due to the non-trivial number of Win32 apps that depended on it. This is a meaningful improvement in terms of ensuring the local server always has a trustworthy origin to check against.
Longer term, I'm excited to see how far we can go with CORS-RFC1918. Edge's use of AppContainer network isolation caused a lot of site compat pain for us, especially as internal enterprise sites started moving into the cloud while still continuing to reference internal hosts via subresources. Finding ways to bring some of those protections back, but in an interoperable fashion, will be really valuable.
Oliver Dunk
Jul 24, 2019, 5:46:39 PM7/24/19
to blink-dev
Is external request a term that already exists? If not, was it discussed much?
I personally find it a bit confusing. Without reading the spec, I would assume that an internal request is one from my site to itself, and that an external request is from my site to anywhere else on the internet. I'm not sure what term would be better - locally directed request might be clearer, but admittedly that's the first thing that came to mind without giving it much thought.
tit...@chromium.org
Sep 14, 2020, 11:29:07 AM9/14/20
to blink-dev
Hi all,
We have shipped basic functionality implementing this change in M86 behind a disabled-by-default feature flag. We are planning to start experimenting in M87 in dev/canary/beta.
We are actively seeking feedback from interested parties in order to determine how to proceed with an eventual launch to stable. Here is a short guide for testers. We are actively discussing the issues facing hybrid public/private webapps stemming from the intersection of this change, mixed-content blocking and the general difficulty in obtaining secure connections to private servers.
Note that the naming has changed since this thread was kicked off: external requests have been renamed to private network requests (see spec PR). This is still imperfect but we believe it conveys the idea more effectively.
Cheers,
Titouan
Reply all
Reply to author
Forward
0 new messages