Mitigate the risks associated with unintentional exposure of devices and servers on a client’s internal network to the web at large.
Malicious websites making requests to devices and servers hosted on a private network have long been a threat. Attackers may, for example, change a wireless router's configuration to enable Man-in-the-Middle attacks. CORS-RFC1918 is a proposal to block such requests by default on the browser and require internal devices to opt-in to requests from the public internet.
To understand how this change impacts the web ecosystem, the Chrome team is looking for feedback from developers who build servers for private networks.
What's wrong with the status quo?
Many web servers run within a private network—wireless routers, printers, intranet websites, enterprise services, and Internet of Things (IoT) devices are only part of them. They might seem to be in a safer environment than the ones exposed to the public but those servers can be abused by attackers using a web page as a proxy. For example, malicious websites can embed a URL that, when simply viewed by the victim (on a JavaScript-enabled browser), attempts to change the DNS server settings on the victim's home broadband router. This type of attack is called "Drive-By Pharming" and it happened in 2014. More than 300,000 vulnerable wireless routers were exploited by having their DNS settings changed and allowing attackers to redirect users to malicious servers.
CORS-RFC1918
To mitigate the threat of similar attacks, the web community is bringing CORS-RFC1918—Cross Origin Resource Sharing (CORS) specialized for private networks defined in RFC1918.
Browsers that implement CORS check with target resources whether they are okay being loaded from a different origin. This is accomplished either with extra headers inline describing the access or by using a mechanism called preflight requests, depending on the complexity. Read Cross Origin Resource Sharing to learn more.
With CORS-RFC1918 the browser will block loading resources over the private network by default except ones that are explicitly allowed by the server using CORS and through HTTPS. The website making requests to those resources will need to send CORS headers and the server will need to explicitly state that it accepts the cross-origin request by responding with corresponding CORS headers. (The exact CORS headers are still under development.)
Developers of such devices or servers will be requested to do two things:
- Make sure the website making requests to a private network is served over HTTPS.
- Set up the server support for CORS-RFC1918 and respond with expected HTTP headers.
What kinds of requests are affected?
Affected requests include:
- Requests from the public network to a private network
- Requests from a private network to a local network
- Requests from the public network to a local network
A private network
A destination that resolves to the private address space defined in Section 3 of
RFC1918 in IPv4, an IPv4-mapped IPv6
address where the mapped IPv4 address is itself private, or an IPv6 address
outside the ::1/128, 2000::/3 and ff00::/8 subnets.
A local network
A destination that resolves to the "loopback" space (127.0.0.0/8) defined in
section 3.2.1.3 of RFC1122 of IPv4, the
"link-local" space (169.254.0.0/16) defined in
RFC3927 of IPv4, the "Unique Local
Address" prefix (fc00::/7) defined in Section 3 of
RFC4193 of IPv6, or the "link-local"
prefix (fe80::/10) defined in section 2.5.6 of
RFC4291 of IPv6.
A public network All others.
Chrome's plans to enable CORS-RFC1918
Chrome is bringing CORS-RFC1918 in two steps:
Step 1: Requests to private network resources will be allowed only from HTTPS web pages
Chrome 87 adds a flag that mandates public websites making requests to private
network resources to be on HTTPS. You can go to
about://flags#block-insecure-private-network-requests to enable it. With this
flag turned on, any requests to a private network resource from an HTTP website
will be blocked.
Starting from Chrome 88, CORS-RFC1918 errors will be reported as CORS policy errors in the console.
In the Network panel of Chrome DevTools you can enable the Blocked Requests checkbox to focus in on blocked requests:
In Chrome 87, CORS-RFC1918 errors are only reported in the DevTools Console as
ERR_INSECURE_PRIVATE_NETWORK_REQUEST instead.
You can try it out yourself using this test website.
Step 2: Sending preflight requests with a special header
In the future, whenever a public website is trying to fetch resources from a private or a local network, Chrome will send a preflight request before the actual request.
The request will include an Access-Control-Request-Private-Network: true
header in addition to other CORS request headers. Among other things, these
headers identify the origin making the request, allowing for fine-grained access
control. The server can respond with an Access-Control-Allow-Private-Network:
true header to explicitly indicate that it grants access to the resource.
Feedback wanted
If you are hosting a website within a private network that expects requests from public networks, the Chrome team is interested in your feedback and use cases. There are two things you can do to help:
- Go to
about://flags#block-insecure-private-network-requests, turn on the flag and see if your website sends requests to the private network resource as expected. - If you encounter any issues or have feedback, file an issue at
crbug.com
and set the component to
Blink>SecurityFeature>CORS>RFC1918.
Example feedback
Our wireless router serves an admin website for the same private network but through HTTP. If HTTPS is required for websites that embed the admin website, it will be mixed content. Should we enable HTTPS on the admin website in a closed network?
This is exactly the type of feedback Chrome is looking for. Please file an issue with your concrete use case at crbug.com. Chrome would love to hear from you.
Hero image by Stephen Philips on Unsplash.