Private Network Access: introductie van preflights

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

Updates

• 7 juli 2022 : huidige status bijgewerkt en definitie van IP-adresruimte toegevoegd.
• 27 april 2022 : bijgewerkte tijdlijnaankondiging.
• 7 maart 2022 : Aangekondigde terugdraaiing nadat er problemen waren ontdekt in Chrome 98.

Invoering

Chrome beëindigt directe toegang tot particuliere netwerkeindpunten vanaf openbare websites als onderdeel van de Private Network Access (PNA)-specificatie.

Chrome begint met het verzenden van een CORS-preflightverzoek voorafgaand aan elk particulier netwerkverzoek voor een subresource, waarin om expliciete toestemming van de doelserver wordt gevraagd. Dit preflightverzoek heeft een nieuwe header, Access-Control-Request-Private-Network: true , en het antwoord daarop moet een overeenkomstige header hebben, Access-Control-Allow-Private-Network: true .

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

Uitrolplan

Chrome zal deze wijziging in twee fasen doorvoeren om websites de tijd te geven de wijziging op te merken en zich dienovereenkomstig aan te passen.

1. In Chrome 104:

   • Chrome experimenteert door preflightverzoeken te verzenden vóór verzoeken om subresources van particuliere netwerken.
   • Preflight-fouten geven alleen waarschuwingen weer in DevTools, zonder de particuliere netwerkverzoeken anderszins te beïnvloeden.
   • Chrome verzamelt compatibiliteitsgegevens en neemt contact op met de grootste getroffen websites.
   • We verwachten dat dit in grote lijnen compatibel zal zijn met bestaande websites.
   Waarschuwing: om de effecten op websites die preflights nog niet ondersteunen te beperken, is de time-out in Chrome 104 beperkt tot 200 milliseconden. De beperking wordt alleen toegepast in de waarschuwingsmodus. De speciale time-outlimiet wordt verwijderd nadat u de afdwingingsmodus hebt ingeschakeld door 'Respecteer het resultaat van preflights voor particuliere netwerktoegang' in chrome://flags te wijzigen in 'Ingeschakeld' en de standaardlimiet is 5 seconden.

2. Op zijn vroegst in Chrome 113:

   • Dit begint alleen als en wanneer compatibiliteitsgegevens aangeven dat de wijziging veilig genoeg is en we indien nodig direct contact hebben opgenomen.
   • Chrome dwingt af dat preflightverzoeken moeten slagen, anders mislukken de verzoeken.
   • Op hetzelfde moment begint een beëindigingsproef, zodat websites die in deze fase betrokken zijn, een verlenging van de tijd kunnen aanvragen. De proef zal minimaal 6 maanden duren.

Let op: Er is al eerder geprobeerd om waarschuwingen uit te rollen in Chrome 98 en Chrome 102, eerder aangekondigd in deze blogpost. Dit is teruggedraaid nadat tijdens de implementatie stabiliteits- en compatibiliteitsproblemen waren ontdekt. De geïdentificeerde problemen zijn opgelost voor Chrome 104.

Wat is particuliere netwerktoegang (PNA)

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

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

De specificatie breidt ook het Cross-Origin Resource Sharing (CORS)-protocol uit, zodat websites nu expliciet een subsidie ​​moeten aanvragen bij servers op particuliere netwerken voordat ze willekeurige verzoeken mogen verzenden.

Sleutelbegrip: Privé-netwerkverzoeken zijn verzoeken waarvan het IP-adres van de doelserver meer privé is dan dat waarvan de verzoekinitiator is opgehaald. Bijvoorbeeld een verzoek van een openbare website ( https://example.com ) aan een privéwebsite ( http://router.local ), of een verzoek van een privéwebsite aan localhost.

Hoe classificeert PNA IP-adressen en identificeert een particulier netwerk

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

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

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

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

Een lokaal IP-adres wordt als privéer beschouwd dan een privé IP-adres dat als privéer wordt beschouwd dan een openbaar IP-adres.

Relatie tussen publieke, private en lokale netwerken in Private Network Access (CORS-RFC1918)

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

Preflight-verzoeken

Achtergrond

Preflightverzoeken zijn een mechanisme dat is geïntroduceerd door de Cross-Origin Resource Sharing (CORS) -standaard en wordt gebruikt om toestemming te vragen aan een doelwebsite voordat deze een HTTP-verzoek verzendt 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 komende HTTP-verzoek beschrijven. Het antwoord moet specifieke CORS-antwoordheaders bevatten waarin expliciet wordt ingestemd met het komende verzoek.

Wat is er nieuw in Private Network Access

Er wordt een nieuw paar request- en response-headers geïntroduceerd voor preflight-aanvragen:

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

Preflightverzoeken voor PNA worden verzonden voor alle particuliere netwerkverzoeken, ongeacht de verzoekmethode en -modus . Ze worden voorafgaand aan verzoeken verzonden in cors -modus, evenals in no-cors en alle andere modi. Dit komt omdat alle particuliere netwerkverzoeken kunnen worden gebruikt voor CSRF-aanvallen, ongeacht de verzoekmodus en ongeacht of de antwoordinhoud al dan niet beschikbaar wordt gesteld aan de initiator.

Opmerking: als het particuliere netwerkverzoek in cors -modus wordt gedaan, moeten CORS-headers worden ingesteld op het uiteindelijke antwoord, naast het preflight-antwoord.

Preflight-aanvragen voor PNA worden ook verzonden voor aanvragen van dezelfde oorsprong, als het doel-IP-adres meer privé is dan de initiator. Dit is anders dan reguliere CORS, waarbij preflight-aanvragen alleen voor cross-origin-aanvragen zijn. Preflight-verzoeken voor verzoeken van dezelfde oorsprong beschermen tegen DNS-rebinding- aanvallen.

Voorbeelden

Waarneembaar gedrag is afhankelijk van de modus van het verzoek .

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 verzendt eerst een preflightverzoek:

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 reageren met:

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

Waarschuwing: de server kan Access-Control-Allow-Origin: * instellen, hoewel dit gevaarlijk en ontmoedigd is. Particuliere netwerkbronnen zouden zelden voor iedereen toegankelijk moeten zijn, dus denk goed na over de risico's die gepaard gaan met het instellen van een dergelijke header.

Vervolgens verzendt 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',
})

Nogmaals, zeg dat bar.example wordt omgezet in 192.168.1.1 .

Chrome verzendt eerst een preflightverzoek:

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 reageren 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 verzendt 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 getroffen is?

Als er vanaf Chrome 104 een privé-netwerkverzoek wordt gedetecteerd, wordt er vooraf een preflightverzoek verzonden. Als dit preflightverzoek mislukt, wordt het laatste verzoek nog steeds verzonden, maar wordt er een waarschuwing weergegeven in het DevTools-problemenpaneel.

Getroffen preflightverzoeken kunnen ook worden bekeken en gediagnosticeerd in het netwerkpaneel:

Als uw verzoek een reguliere CORS-preflight zou hebben geactiveerd zonder regels voor privénetwerktoegang, 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 veilig negeren.

Als u wilt bekijken wat er gebeurt als preflight-succes wordt 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 zou werken na de tweede fase van ons uitrolplan . Fouten kunnen op dezelfde manier worden gediagnosticeerd als waarschuwingen met behulp van de hierboven genoemde DevTools-panelen.

Wat u moet doen als uw website getroffen is

Wanneer deze wijziging wordt doorgevoerd in Chrome 104, wordt niet verwacht dat deze een website kapot zal maken. We raden u echter ten zeerste aan de betreffende aanvraagpaden bij te werken om ervoor te zorgen dat uw website blijft werken zoals verwacht.

Er zijn twee oplossingen voor u beschikbaar:

1. Behandel preflightverzoeken aan de serverzijde
2. Schakel PNA-controles uit met bedrijfsbeleid

Behandel preflightverzoeken op de server

Update de doelserver van eventuele getroffen ophaalacties om PNA-preflightverzoeken af ​​te handelen. Implementeer eerst ondersteuning voor standaard CORS-preflightverzoeken op getroffen routes. Voeg vervolgens ondersteuning toe voor de twee nieuwe antwoordheaders .

Wanneer uw server een preflight-verzoek 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 onderzoeken, samen met andere relevante informatie (zoals Access-Control-Request-Headers ) om er zeker van te zijn dat het verzoek veilig kan worden toegestaan. Normaal gesproken moet u toegang toestaan ​​tot één enkele oorsprong die u beheert.

Waarschuwing: pas op voor onveilige (niet-https) oorsprongen, aangezien deze niet zijn geverifieerd. Een aanvaller op het pad zou zich kunnen voordoen als een dergelijke oorsprong!

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

Raadpleeg de voorbeelden voor concrete scenario's.

Schakel controles op particuliere netwerktoegang uit met behulp van bedrijfsbeleid

Als u beheerderscontrole over uw gebruikers heeft, kunt u de controles op privénetwerktoegang uitschakelen met behulp van een van de volgende beleidsregels:

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

Voor meer informatie raadpleegt u Chrome-beleidsbeheer begrijpen .

Geef ons feedback

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

Wat is het volgende

Vervolgens breidt Chrome de controles op privénetwerktoegang uit naar webwerkers : toegewijde werkers, gedeelde werkers en servicewerkers. We streven er voorlopig naar dat Chrome 107 waarschuwingen gaat weergeven.

Vervolgens breidt Chrome de controles op privénetwerktoegang uit tot navigatie, inclusief iframes en pop-ups. We streven er voorlopig naar dat Chrome 108 waarschuwingen gaat weergeven.

In beide gevallen zullen we voorzichtig te werk gaan met een soortgelijke gefaseerde uitrol, om webontwikkelaars de tijd te geven zich aan te passen en het compatibiliteitsrisico in te schatten.

Dankbetuigingen

Omslagfoto door Mark Olsen op Unsplash .