Beperk de risico's die gepaard gaan met onbedoelde blootstelling van apparaten en servers op het interne netwerk van een klant aan het internet als geheel.
Schadelijke websites die verzoeken indienen bij apparaten en servers die op een particulier netwerk worden gehost, 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 zich aanmelden voor verzoeken van het openbare internet.
Om te begrijpen hoe deze verandering het web-ecosysteem 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 particulier netwerk; draadloze routers, printers, intranetwebsites, bedrijfsservices en Internet of Things (IoT)-apparaten zijn daar slechts een deel van. Het lijkt erop dat ze zich in een veiligere omgeving bevinden dan de servers die aan het publiek worden blootgesteld, maar deze servers kunnen worden misbruikt door aanvallers die een webpagina als proxy gebruiken. Kwaadaardige websites kunnen bijvoorbeeld een URL insluiten die, wanneer deze eenvoudigweg door het slachtoffer wordt bekeken (in een browser met JavaScript), probeert de DNS-serverinstellingen op de breedbandrouter thuis van het slachtoffer te wijzigen. Dit type aanval heet ‘ Drive-By Pharming ’ en vond plaats in 2014 . Meer dan 300.000 kwetsbare draadloze routers werden uitgebuit door hun DNS-instellingen te wijzigen, waardoor aanvallers gebruikers konden omleiden naar kwaadaardige servers.
CORS-RFC1918
Om de dreiging van soortgelijke aanvallen te beperken, brengt de webgemeenschap CORS-RFC1918 uit: Cross Origin Resource Sharing (CORS), gespecialiseerd voor particuliere netwerken gedefinieerd in RFC1918 .
Browsers die CORS implementeren, controleren bij doelbronnen of het goed is dat ze vanaf een andere oorsprong worden geladen. Dit wordt bereikt door extra headers inline die de toegang beschrijven, of door een mechanisme te gebruiken dat preflight-verzoeken wordt genoemd, 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 met behulp van CORS en via HTTPS. De website die verzoeken naar deze bronnen doet, moet CORS-headers verzenden en de server moet expliciet aangeven dat hij het cross-origin-verzoek accepteert door te reageren met overeenkomstige CORS-headers. (De exacte CORS-headers zijn nog in ontwikkeling.)
Ontwikkelaars van dergelijke apparaten of servers zullen twee dingen moeten doen:
- Zorg ervoor dat de website die verzoeken indient bij een particulier netwerk via HTTPS wordt bediend.
- Stel de serverondersteuning voor CORS-RFC1918 in en reageer met de verwachte HTTP-headers.
Om welke soorten verzoeken gaat het?
Betrokken verzoeken zijn onder meer:
- Verzoeken van het openbare netwerk naar een particulier netwerk
- Verzoeken van een particulier netwerk naar een lokaal netwerk
- Verzoeken van het openbare netwerk naar een lokaal netwerk
Een particulier netwerk Een bestemming die wordt omgezet in de privé-adresruimte gedefinieerd in Sectie 3 van RFC1918 in IPv4, een IPv4-toegewezen IPv6-adres waarbij het toegewezen 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 wordt omgezet 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 voorvoegsel "Uniek lokaal adres" ( fc00::/7 ) gedefinieerd in sectie 3 van RFC4193 van IPv6, of het voorvoegsel "link-local" ( fe80::/10 ) gedefinieerd in sectie 2.5.6 van RFC4291 van IPv6.
Een openbaar netwerk Alle anderen.
Chrome's plannen om CORS-RFC1918 in te schakelen
Chrome brengt CORS-RFC1918 in twee stappen:
Stap 1: Verzoeken aan particuliere netwerkbronnen zijn alleen toegestaan vanaf HTTPS-webpagina's
Chrome 87 voegt een vlag toe die ervoor zorgt dat openbare websites die verzoeken indienen bij particuliere netwerkbronnen, zich op HTTPS moeten bevinden. U kunt naar about://flags#block-insecure-private-network-requests gaan om dit in te schakelen. Als deze vlag is ingeschakeld, worden alle verzoeken aan een particuliere netwerkbron vanaf een HTTP-website geblokkeerd.
Vanaf Chrome 88 worden CORS-RFC1918-fouten gerapporteerd als CORS-beleidsfouten in de console.
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 in de DevTools-console alleen gerapporteerd als ERR_INSECURE_PRIVATE_NETWORK_REQUEST .
Via deze testwebsite kunt u het zelf uitproberen.
Stap 2: Preflight-verzoeken verzenden met een speciale header
Wanneer een openbare website in de toekomst bronnen probeert op te halen van een particulier of lokaal netwerk, zal Chrome in de toekomst een preflightverzoek sturen vóór het daadwerkelijke verzoek.
Het verzoek bevat een Access-Control-Request-Private-Network: true header naast andere CORS-verzoekheaders. Deze headers identificeren onder andere de oorsprong van het verzoek, waardoor een fijnmazige toegangscontrole mogelijk is. De server kan reageren met een Access-Control-Allow-Private-Network: true header om expliciet aan te geven dat hij toegang verleent tot de bron.
Feedback gewenst
Als u een website host binnen een particulier netwerk dat verzoeken van openbare netwerken verwacht, is het Chrome-team geïnteresseerd in uw feedback en gebruiksscenario's. Er zijn twee dingen die u kunt doen om te helpen:
- Ga naar
about://flags#block-insecure-private-network-requests, schakel de vlag in en kijk of uw website zoals verwacht verzoeken naar de particuliere netwerkbron verzendt. - Als u problemen ondervindt of feedback heeft, dient u een probleem in op crbug.com en stelt u de component in op
Blink>SecurityFeature>CORS>RFC1918.
Voorbeeld feedback
Onze draadloze router bedient een beheerderswebsite voor hetzelfde privénetwerk, maar dan via HTTP. Als HTTPS vereist is voor websites die de beheerderswebsite insluiten, is er sprake van gemengde inhoud. Moeten we HTTPS inschakelen op de beheerderswebsite in een gesloten netwerk?
Dit is precies het soort feedback waar Chrome naar op zoek is. Dien een probleem met uw concrete gebruikssituatie in op crbug.com . Chrome hoort graag van u.
Hero-afbeelding door Stephen Philips op Unsplash .