Private Network Access: introductie van preflights

Titouan Rigoudy
Titouan Rigoudy
Eiji Kitamura
Yifan Luo
Yifan Luo
GitHub

Updates

  • 7 juli 2022 : huidige status bijgewerkt en definitie van IP-adresruimte toegevoegd.
  • 27 april 2022 : aankondiging van de bijgewerkte tijdlijn.
  • 7 maart 2022 : Terugdraaiing aangekondigd nadat er problemen waren ontdekt in Chrome 98.

Invoering

Chrome stopt met directe toegang tot privénetwerkeindpunten vanaf openbare websites als onderdeel van de Private Network Access (PNA)-specificatie.

Chrome begint met het versturen van een CORS-preflightverzoek vóór elk verzoek voor een privénetwerk voor een subresource, waarin expliciet toestemming wordt gevraagd aan de doelserver. Dit preflightverzoek krijgt een nieuwe header, Access-Control-Request-Private-Network: true , en het antwoord hierop moet een bijbehorende header bevatten, Access-Control-Allow-Private-Network: true .

Het doel is om gebruikers te beschermen tegen cross-site request forgery (CSRF)-aanvallen die gericht zijn op routers en andere apparaten in privénetwerken. Deze aanvallen hebben honderdduizenden gebruikers getroffen , waardoor aanvallers hen naar kwaadaardige servers konden omleiden.

Uitrolplan

Chrome voert deze wijziging in twee fasen in, zodat websites voldoende tijd hebben om de wijziging op te merken en zich hierop aan te passen.

  1. In Chrome 104:

    • Chrome experimenteert door preflight-aanvragen te versturen voorafgaand aan subresource-aanvragen voor privénetwerken.
    • Bij preflight-fouten worden alleen waarschuwingen in DevTools weergegeven, zonder dat dit anderszins van invloed is op de verzoeken van het privénetwerk.
    • Chrome verzamelt compatibiliteitsgegevens en neemt contact op met de grootste getroffen websites.
    • Wij verwachten dat dit grotendeels compatibel zal zijn met bestaande websites.

  2. In Chrome 113 is dit op zijn vroegst het geval:

    • Dit zal alleen gebeuren als en wanneer compatibiliteitsgegevens aangeven dat de wijziging veilig genoeg is en wij indien nodig rechtstreeks contact met u hebben opgenomen.
    • Chrome zorgt ervoor dat preflight-aanvragen moeten slagen, anders mislukken de aanvragen.
    • Tegelijkertijd start een proefperiode waarin websites die door deze fase worden getroffen een verlenging kunnen aanvragen. De proefperiode duurt minimaal 6 maanden.

Wat is Private Network Access (PNA)

Private Network Access (voorheen bekend als CORS-RFC1918 ) beperkt de mogelijkheid van websites om verzoeken te sturen naar servers op privénetwerken.

Chrome heeft een deel van de specificatie al geïmplementeerd: vanaf Chrome 96 mogen alleen beveiligde contexten verzoeken voor privénetwerken doen. Raadpleeg onze vorige blogpost voor meer informatie.

De specificatie breidt bovendien het Cross-Origin Resource Sharing (CORS)-protocol uit, waardoor websites nu expliciet een verzoek tot toestemming moeten indienen bij servers op particuliere netwerken voordat ze willekeurige verzoeken mogen versturen.

Hoe classificeert PNA IP-adressen en identificeert het een privénetwerk?

De IP-adressen worden ingedeeld in drie IP-adresruimten: - public - private - local

De lokale IP-adresruimte bevat IP-adressen die IPv4-loopbackadressen ( 127.0.0.0/8 ) zijn, gedefinieerd in sectie 3.2.1.3 van RFC1122 , of IPv6-loopbackadressen ( ::1/128 ) zijn, gedefinieerd in sectie 2.5.3 van RFC4291 .

De privé-IP-adresruimte bevat IP-adressen die alleen binnen het huidige netwerk betekenis hebben, waaronder 10.0.0.0/8 , 172.16.0.0/12 en 192.168.0.0/16 zoals gedefinieerd in RFC1918 , link-lokale adressen 169.254.0.0/16 zoals gedefinieerd in RFC3927 , unieke lokale IPv6-unicastadressen fc00::/7 zoals gedefinieerd in RFC4193 , link-lokale IPv6-unicastadressen fe80::/10 zoals gedefinieerd in sectie 2.5.6 van RFC4291 en via IPv4 toegewezen IPv6-adressen waarbij het toegewezen IPv4-adres zelf privé is.

De openbare IP-adresruimte bevat alle andere adressen die hier niet eerder zijn genoemd.

Een lokaal IP-adres wordt als meer privé beschouwd dan een privé-IP-adres, dat op zijn beurt weer als meer privé wordt beschouwd dan een openbaar IP-adres.

Verzoeken zijn privé wanneer een beter beschikbaar netwerk een verzoek stuurt naar een minder beschikbaar netwerk.
Relatie tussen openbare, privé- en lokale netwerken in Private Network Access (CORS-RFC1918)

Meer informatie vindt u op Feedback gewenst: CORS voor particuliere netwerken (RFC1918) .

Preflight-aanvragen

Achtergrond

Preflightverzoeken zijn een mechanisme dat is geïntroduceerd door de Cross-Origin Resource Sharing (CORS) -standaard en dat wordt gebruikt om toestemming te vragen aan een doelwebsite voordat er een HTTP-verzoek wordt verzonden dat mogelijk bijwerkingen heeft. Dit zorgt ervoor dat de doelserver het CORS-protocol begrijpt en vermindert het risico op CSRF-aanvallen aanzienlijk.

Het toestemmingsverzoek wordt verzonden als een OPTIONS HTTP-verzoek met specifieke CORS-verzoekheaders die het aankomende HTTP-verzoek beschrijven. Het antwoord moet specifieke CORS-antwoordheaders bevatten die expliciet instemmen met het aankomende verzoek.

Sequentiediagram dat CORS-preflight weergeeft. Een OPTIONS HTTP-verzoek wordt naar het doel verzonden, dat een 200 OK retourneert. Vervolgens wordt de CORS-verzoekheader verzonden, die een CORS-responsheader retourneert.

Wat is er nieuw in Private Network Access

Er wordt een nieuw paar aanvraag- en antwoordheaders geïntroduceerd voor preflight-aanvragen:

  • Access-Control-Request-Private-Network: true is ingesteld op alle PNA-preflightverzoeken
  • Access-Control-Allow-Private-Network: true moet worden ingesteld op alle PNA-preflightreacties

Preflight-verzoeken voor PNA worden verzonden voor alle verzoeken in private netwerken, ongeacht de aanvraagmethode en -modus . Ze worden vóór verzoeken in cors modus, no-cors en alle andere modi verzonden. Dit komt doordat alle verzoeken in private netwerken kunnen worden gebruikt voor CSRF-aanvallen, ongeacht de aanvraagmodus en of de inhoud van de respons al dan niet beschikbaar is voor de initiator.

Preflightverzoeken voor PNA worden ook verzonden voor verzoeken met dezelfde oorsprong, als het doel-IP-adres privater is dan dat van de initiator. Dit in tegenstelling tot reguliere CORS, waar preflightverzoeken alleen voor verzoeken met een andere oorsprong gelden. Preflightverzoeken voor verzoeken met dezelfde oorsprong bieden bescherming tegen DNS-rebindingaanvallen .

Voorbeelden

Het waarneembare gedrag is afhankelijk van de aanvraagmodus .

Geen-CORS-modus

Zeg https://foo.example/index.html embeds <img src="https://bar.example/cat.gif" alt="dancing cat"/> en bar.example wordt omgezet naar 192.168.1.1 , een privé IP-adres volgens RFC 1918 .

Chrome verstuurt eerst een preflight-verzoek:

HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true

Om dit verzoek te laten slagen, moet de server antwoorden met:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true

Vervolgens verstuurt Chrome het daadwerkelijke verzoek:

HTTP/1.1 GET /cat.gif
...

Waarop de server normaal kan reageren.

CORS-modus

Stel dat https://foo.example/index.html de volgende code uitvoert:

await fetch('https://bar.example/delete-everything', {
  method: 'PUT',
  credentials: 'include',
})

Stel dat bar.example wordt omgezet naar 192.168.1.1 .

Chrome verstuurt eerst een preflight-verzoek:

HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true

Om dit verzoek te laten slagen, moet de server antwoorden met:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true

Vervolgens verstuurt Chrome het daadwerkelijke verzoek:

HTTP/1.1 PUT /delete-everything
Origin: https://foo.example

Waarop de server kan reageren volgens de gebruikelijke CORS-regels:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example

Hoe weet u of uw website is getroffen?

Vanaf Chrome 104 wordt er, als er een verzoek via een privénetwerk wordt gedetecteerd, een preflightverzoek vooraf verzonden. Mislukt dit preflightverzoek, dan wordt het definitieve verzoek alsnog verzonden, maar verschijnt er een waarschuwing in het problemenpaneel van DevTools.

Een waarschuwing voor een mislukte preflight-aanvraag in het paneel Problemen in Devtools. Deze waarschuwing luidt: Zorg ervoor dat privénetwerkaanvragen alleen worden ingediend bij resources die dit toestaan, samen met details over de specifieke aanvraag en de betreffende resources.

Betrokken preflight-aanvragen kunnen ook worden bekeken en gediagnosticeerd in het netwerkpaneel:

Een mislukte preflight-aanvraag in het DevTools-netwerkpaneel voor localhost geeft een 501-status.

Als uw verzoek een normale CORS-preflight zou hebben geactiveerd zonder Private Network Access-regels, kunnen er twee preflights in het netwerkpaneel verschijnen, waarbij de eerste altijd lijkt te zijn mislukt. Dit is een bekende bug en u kunt deze gerust negeren.

Een onterecht mislukte preflightaanvraag vóór een succesvolle preflight in het DevTools Network-paneel.

Om te bekijken wat er gebeurt als preflight-succes is afgedwongen, kunt u het volgende opdrachtregelargument doorgeven , te beginnen in Chrome 98:

--enable-features=PrivateNetworkAccessRespectPreflightResults

Elk mislukt preflightverzoek resulteert in een mislukte ophaalactie. Hiermee kunt u testen of uw website na de tweede fase van ons uitrolplan nog steeds werkt. Fouten kunnen op dezelfde manier worden gediagnosticeerd als waarschuwingen met behulp van de hierboven genoemde DevTools-panels.

Wat u moet doen als uw website is getroffen

Wanneer deze wijziging in Chrome 104 wordt doorgevoerd, wordt niet verwacht dat dit websites zal verstoren. We raden u echter sterk aan de betreffende aanvraagpaden bij te werken om ervoor te zorgen dat uw website naar behoren blijft werken.

Er zijn twee oplossingen voor u beschikbaar:

  1. Preflight-verzoeken aan de serverzijde verwerken
  2. PNA-controles uitschakelen met bedrijfsbeleid

Preflight-verzoeken server-side verwerken

Werk de doelserver van alle betrokken fetches bij om PNA-preflightverzoeken te verwerken. Implementeer eerst ondersteuning voor standaard CORS-preflightverzoeken op de betrokken routes. Voeg vervolgens ondersteuning toe voor de twee nieuwe responsheaders .

Wanneer uw server een preflightverzoek ontvangt (een OPTIONS verzoek met CORS-headers), moet de server controleren op de aanwezigheid van een Access-Control-Request-Private-Network: true header. Als deze header aanwezig is in het verzoek, moet de server de Origin header en het verzoekpad controleren, samen met alle andere relevante informatie (zoals Access-Control-Request-Headers ) om te controleren of het verzoek veilig kan worden toegestaan. Normaal gesproken moet u toegang toestaan ​​tot één oorsprong onder uw beheer.

Zodra uw server heeft besloten het verzoek toe te staan, zou deze moeten reageren 204 No Content (of 200 OK ) met de benodigde CORS-headers en de nieuwe PNA-header. Deze headers bevatten Access-Control-Allow-Origin en Access-Control-Allow-Private-Network: true , evenals andere headers indien nodig.

Raadpleeg de voorbeelden voor concrete scenario's.

Schakel controles op privénetwerktoegang uit met behulp van bedrijfsbeleid

Als u beheerderscontrole over uw gebruikers hebt, kunt u controles op toegang tot privénetwerken uitschakelen met een van de volgende beleidsregels:

Raadpleeg Chrome-beleidsbeheer begrijpen voor meer informatie.

Geef ons feedback

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. Laat het ons weten door een probleem met Chromium te melden op crbug.com en stel het onderdeel in op Blink>SecurityFeature>CORS>PrivateNetworkAccess .

Wat volgt er?

Vervolgens breidt Chrome de Private Network Access-controles uit naar webworkers : dedicated workers, shared workers en serviceworkers. We streven er voorlopig naar dat Chrome 107 waarschuwingen gaat weergeven.

Vervolgens breidt Chrome de Private Network Access-controles uit naar navigatie, inclusief iframes en pop-ups. We streven er voorlopig naar dat Chrome 108 waarschuwingen gaat weergeven.

In beide gevallen gaan we voorzichtig te werk met een gefaseerde uitrol, zodat webontwikkelaars voldoende tijd hebben om zich aan te passen en de compatibiliteitsrisico's in te schatten.

Dankbetuigingen

Coverfoto door Mark Olsen op Unsplash .