Beperk de risico's die gepaard gaan met onbedoelde blootstelling van apparaten en servers op het interne netwerk van een klant aan het internet in het algemeen.
Kwaadwillende websites die verzoeken sturen naar apparaten en servers op een privénetwerk vormen al lange tijd een bedreiging. Aanvallers kunnen bijvoorbeeld de configuratie van een draadloze router wijzigen om Man-in-the-Middle- aanvallen mogelijk te maken. CORS-RFC1918 is een voorstel om dergelijke verzoeken standaard in de browser te blokkeren en te vereisen dat interne apparaten expliciet toestemming geven voor verzoeken vanaf het openbare internet.
Om te begrijpen welke impact deze verandering heeft op het web-ecosysteem, vraagt het Chrome-team om feedback van ontwikkelaars die servers bouwen voor privénetwerken.
Wat is er mis met de huidige situatie?
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
Om de dreiging van soortgelijke aanvallen te beperken, introduceert de webgemeenschap CORS-RFC1918 — Cross Origin Resource Sharing (CORS), een specifieke versie voor privénetwerken zoals gedefinieerd 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.
Met CORS-RFC1918 blokkeert de browser standaard het laden van bronnen via het privénetwerk, behalve bronnen die expliciet door de server zijn toegestaan met behulp van CORS en HTTPS. De website die verzoeken naar deze bronnen stuurt, moet CORS-headers meesturen en de server moet expliciet aangeven dat het cross-origin-verzoek wordt geaccepteerd door te reageren met overeenkomstige CORS-headers. (De exacte CORS-headers worden nog ontwikkeld.)
Aan ontwikkelaars van dergelijke apparaten of servers wordt gevraagd twee dingen te doen:
- Zorg ervoor dat de website die verzoeken naar een privénetwerk stuurt, via HTTPS wordt aangeboden.
- Configureer de serverondersteuning voor CORS-RFC1918 en reageer met de verwachte HTTP-headers.
Welke soorten verzoeken worden hierdoor beïnvloed?
De volgende verzoeken zijn getroffen:
- Verzoeken van het openbare netwerk naar een privénetwerk
- Verzoeken van een privénetwerk naar een lokaal netwerk
- Verzoeken van het openbare netwerk naar een lokaal netwerk
Een privénetwerk: een bestemming die verwijst naar de privé-adresruimte zoals gedefinieerd in sectie 3 van RFC1918 in IPv4, een IPv4-gemapte IPv6-adres waarbij het gemapte IPv4-adres zelf privé is, of een IPv6-adres buiten de ::1/128 , 2000::/3 en ff00::/8 subnetten.
Een lokaal netwerk. Een bestemming die verwijst naar de "loopback"-ruimte ( 127.0.0.0/8 ) zoals gedefinieerd in sectie 3.2.1.3 van RFC1122 van IPv4, de "link-local"-ruimte ( 169.254.0.0/16 ) zoals gedefinieerd in RFC3927 van IPv4, het "Unique Local Address"-prefix ( fc00::/7 ) zoals gedefinieerd in sectie 3 van RFC4193 van IPv6, of het "link-local"-prefix ( fe80::/10 ) zoals gedefinieerd in sectie 2.5.6 van RFC4291 van IPv6.
Een openbaar netwerk . Alle andere.
Chrome is van plan CORS-RFC1918 in te schakelen.
Chrome implementeert CORS-RFC1918 in twee stappen:
Stap 1: Verzoeken aan privénetwerkbronnen zijn alleen toegestaan vanaf HTTPS-webpagina's.
Chrome 87 voegt een vlag toe die vereist dat openbare websites die verzoeken doen aan privénetwerkbronnen, HTTPS gebruiken. Je kunt deze vlag inschakelen via about://flags#block-insecure-private-network-requests . Met deze vlag ingeschakeld worden alle verzoeken aan een privénetwerkbron vanaf een HTTP-website geblokkeerd.
Vanaf Chrome 88 worden CORS-RFC1918-fouten in de console weergegeven als CORS-beleidsfouten.
In het netwerkpaneel van Chrome DevTools kunt u het selectievakje 'Geblokkeerde verzoeken' inschakelen om u te concentreren op geblokkeerde verzoeken:
In Chrome 87 worden CORS-RFC1918-fouten alleen in de DevTools-console weergegeven als ERR_INSECURE_PRIVATE_NETWORK_REQUEST .
Je kunt het zelf uitproberen via deze testwebsite .
Stap 2: Preflight-verzoeken verzenden met een speciale header.
In de toekomst zal Chrome, wanneer een openbare website probeert gegevens op te halen van een privé- of lokaal netwerk, een preflight-verzoek versturen vóór het daadwerkelijke verzoek.
Het verzoek bevat naast andere CORS-verzoekheaders ook de header Access-Control-Request-Private-Network: true . Deze headers identificeren onder andere de oorsprong van het verzoek, waardoor nauwkeurige toegangscontrole mogelijk is. De server kan reageren met de header Access-Control-Allow-Private-Network: true om expliciet aan te geven dat toegang tot de bron wordt verleend.
Feedback gewenst
Als je een website host binnen een privénetwerk die verzoeken verwacht van openbare netwerken, dan is het Chrome-team geïnteresseerd in je feedback en gebruiksscenario's. Er zijn twee dingen die je kunt doen om te helpen:
- Ga naar
about://flags#block-insecure-private-network-requests, schakel de vlag in en controleer of uw website zoals verwacht verzoeken naar de privénetwerkbron verzendt. - Als je problemen ondervindt of feedback hebt, meld dit dan via crbug.com en stel de component in op
Blink>SecurityFeature>CORS>RFC1918.
Voorbeeld van feedback
Onze draadloze router host een beheerderswebsite voor hetzelfde privénetwerk, maar via HTTP. Als HTTPS vereist is voor websites die de beheerderswebsite embedden, ontstaat er gemengde content. Moeten we HTTPS inschakelen voor de beheerderswebsite in een gesloten netwerk?
Dit is precies het soort feedback waar Chrome naar op zoek is. Meld een probleem met uw concrete gebruikssituatie op crbug.com . Chrome hoort graag van u.