Beperk de risico's die samenhangen met onbedoelde blootstelling van apparaten en servers op het interne netwerk van een klant aan het internet in het algemeen.
Kwaadaardige websites die verzoeken sturen naar apparaten en servers die op een privénetwerk worden gehost, vormen al lang 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 interne apparaten te verplichten zich aan te melden voor verzoeken van het openbare internet.
Om te begrijpen hoe deze verandering het webecosysteem beïnvloedt, is het Chrome-team op zoek naar feedback van ontwikkelaars die servers voor privénetwerken bouwen.
Wat is er mis met de status quo?
Veel webservers draaien binnen een privénetwerk – draadloze routers, printers, intranetwebsites, zakelijke services en IoT-apparaten (Internet of Things) zijn daar slechts een onderdeel van. Ze lijken zich in een veiligere omgeving te bevinden dan de servers die openbaar toegankelijk zijn, maar die servers kunnen worden misbruikt door aanvallers die een webpagina als proxy gebruiken. Kwaadaardige websites kunnen bijvoorbeeld een URL insluiten die, wanneer deze door het slachtoffer wordt bekeken (in een browser met JavaScript), probeert de DNS-serverinstellingen op de breedbandrouter van het slachtoffer te wijzigen. Dit type aanval wordt " Drive-By Pharming " genoemd en vond plaats in 2014. Meer dan 300.000 kwetsbare draadloze routers werden misbruikt door hun DNS-instellingen te wijzigen, waardoor aanvallers gebruikers naar kwaadaardige servers konden omleiden.
CORS-RFC1918
Om de dreiging van soortgelijke aanvallen te beperken, introduceert de webcommunity CORS-RFC1918 — Cross Origin Resource Sharing (CORS) dat speciaal is ontwikkeld voor particuliere netwerken, zoals gedefinieerd in RFC1918 .
Browsers die CORS implementeren, controleren bij doelresources of deze geladen kunnen worden vanaf een andere bron. Dit wordt bereikt met extra headers inline die de toegang beschrijven of met behulp van een mechanisme genaamd preflight requests, afhankelijk van de complexiteit. Lees Cross Origin Resource Sharing voor meer informatie.
Met CORS-RFC1918 blokkeert de browser standaard het laden van bronnen via het privénetwerk, behalve bronnen die expliciet zijn toegestaan door de server via CORS en HTTPS. De website die verzoeken naar deze bronnen stuurt, moet CORS-headers verzenden en de server moet expliciet aangeven dat hij de cross-origin-aanvraag accepteert door te reageren met de bijbehorende CORS-headers. (De exacte CORS-headers zijn nog in ontwikkeling.)
Van ontwikkelaars van dergelijke apparaten of servers wordt verwacht dat ze twee dingen doen:
- Zorg ervoor dat de website die verzoeken naar een privénetwerk stuurt, via HTTPS wordt bediend.
- Stel de serverondersteuning voor CORS-RFC1918 in en reageer met de verwachte HTTP-headers.
Welke soorten verzoeken worden hierdoor getroffen?
Betreffende verzoeken zijn onder meer:
- 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 wordt omgezet naar de privéadresruimte zoals gedefinieerd in Sectie 3 van RFC1918 in IPv4, een via IPv4 toegewezen IPv6-adres waarbij het toegewezen IPv4-adres zelf privé is, of een IPv6-adres buiten de subnetten ::1/128 , 2000::/3 en ff00::/8 .
Een lokaal netwerk Een bestemming die verwijst naar de "loopback"-ruimte ( 127.0.0.0/8 ) gedefinieerd in sectie 3.2.1.3 van RFC1122 van IPv4, de "link-local"-ruimte ( 169.254.0.0/16 ) gedefinieerd in RFC3927 van IPv4, het "Unique Local Address"-prefix ( fc00::/7 ) gedefinieerd in sectie 3 van RFC4193 van IPv6, of het "link-local"-prefix ( fe80::/10 ) gedefinieerd in sectie 2.5.6 van RFC4291 van IPv6.
Een openbaar netwerk. Alle anderen.
Chrome's plannen om CORS-RFC1918 mogelijk te maken
Chrome introduceert CORS-RFC1918 in twee stappen:
Stap 1: Verzoeken aan privénetwerkbronnen worden alleen toegestaan vanaf HTTPS-webpagina's
Chrome 87 voegt een vlag toe die vereist dat openbare websites die verzoeken naar privénetwerkbronnen sturen, HTTPS gebruiken. Ga naar about://flags#block-insecure-private-network-requests om deze in te schakelen. Met deze vlag ingeschakeld, worden alle verzoeken naar een privénetwerkbron vanaf een HTTP-website geblokkeerd.
Vanaf Chrome 88 worden CORS-RFC1918-fouten gerapporteerd als CORS-beleidsfouten in de console.
In het paneel Netwerk van Chrome DevTools kunt u het selectievakje Geblokkeerde verzoeken inschakelen om de focus te leggen op geblokkeerde verzoeken:
In Chrome 87 worden CORS-RFC1918-fouten alleen in de DevTools Console gerapporteerd als ERR_INSECURE_PRIVATE_NETWORK_REQUEST .
U kunt het zelf uitproberen via deze testwebsite .
Stap 2: Preflight-verzoeken verzenden met een speciale header
Wanneer een openbare website in de toekomst bronnen van een privé- of lokaal netwerk probeert op te halen, zal Chrome een preflight-aanvraag versturen vóór de daadwerkelijke aanvraag.
Het verzoek bevat een Access-Control-Request-Private-Network: true header, naast andere CORS-verzoekheaders. Deze headers identificeren onder andere de bron van het verzoek, wat een gedetailleerde toegangscontrole mogelijk maakt. De server kan reageren met een Access-Control-Allow-Private-Network: true header om expliciet aan te geven dat toegang tot de resource wordt verleend.
Feedback gewenst
Als u een website host binnen een privénetwerk dat verzoeken van openbare netwerken verwacht, is het Chrome-team geïnteresseerd in uw feedback en use cases. U kunt twee dingen doen om te helpen:
- Ga naar
about://flags#block-insecure-private-network-requests, schakel de vlag in en kijk of uw website verzoeken naar de privénetwerkbron verzendt zoals verwacht. - Als u problemen ondervindt of feedback hebt, kunt u dit melden op crbug.com en het onderdeel instellen op
Blink>SecurityFeature>CORS>RFC1918.
Voorbeeldfeedback
Onze draadloze router bedient een beheerderswebsite voor hetzelfde privénetwerk, maar dan via HTTP. Als HTTPS vereist is voor websites die de beheerderswebsite integreren, zal dit gemengde content zijn. Moeten we HTTPS inschakelen op de beheerderswebsite in een gesloten netwerk?
Dit is precies het soort feedback waar Chrome naar op zoek is. Meld een probleem met uw concrete use case op crbug.com . Chrome hoort graag van u.
Hero-afbeelding door Stephen Philips op Unsplash .