De proefperiode voor Private Network Access (PNA) voor niet-beveiligde contexten loopt ten einde: implementeer de PNA-toestemmingsprompt

Yifan Luo
Yifan Luo
GitHub

Chrome 124 bevat de toestemming voor privénetwerktoegang om de functie voor gemengde inhoud te versoepelen . Er loopt een proefperiode voor sites die meer tijd nodig hebben om zich op deze wijziging voor te bereiden. Deze proefperiode eindigt echter met Chrome 126, dat naar verwachting op 4 september 2024 wordt verzonden. In dit bericht wordt de wijziging uitgelegd, meer over het ontwerp van de functie, hoe om uw huidige websites te migreren en hoe u uw implementatie kunt testen.

Wat verandert er?

Om verbindingen tot stand te brengen met apparaten op een particulier netwerk die geen globaal unieke namen hebben en daarom geen TLS-certificaten kunnen verkrijgen, introduceert deze functie een nieuwe optie om fetch() aan te geven om de intentie van een ontwikkelaar aan te geven om met een dergelijk apparaat te praten. Dit omvat een nieuwe beleidsgestuurde functie om de toegang van elke site tot deze mogelijkheid af te sluiten, en nieuwe headers voor de preflight-reactie van de server om aanvullende metagegevens te leveren.

Wat is particuliere netwerktoegang?

Private Network Access (PNA, voorheen bekend als CORS-RFC1918 en kortweg Local Network Access) is een beveiligingsfunctie die de mogelijkheid van websites beperkt om verzoeken naar servers op particuliere netwerken te sturen. Dit helpt gebruikers en interne netwerken te beschermen tegen mogelijke aanvallen zoals Cross-Site Request Forgery (CSRF). Chrome heeft PNA geleidelijk geïmplementeerd en de bescherming zal in komende releases worden uitgebreid.

Waarom is een toestemmingsprompt nodig?

Chrome 94 introduceerde een blokkering van de toegang tot privénetwerken vanaf niet-beveiligde openbare websites. De lopende proef voor de beëindiging van Private Network Access vanuit niet-beveiligde contexten heeft problemen aan het licht gebracht bij het migreren van getroffen websites naar HTTPS. Een veelvoorkomend probleem is de moeilijkheid om privé-apparaten naar HTTPS te migreren, wat leidt tot overtredingen van gemengde inhoudscontroles.

Om dit probleem aan te pakken, is er een nieuwe toestemmingsprompt toegevoegd onder een origin-proefversie van Chrome 120 en in stable van Chrome 124.

Wanneer is een toestemmingsprompt nodig?

We waren van plan de proefperiode voor het beëindigen van niet-beveiligde contexten te beëindigen enkele mijlpalen nadat de functie voor toestemmingsprompts beschikbaar kwam. Om compatibiliteit te garanderen, moet u uw openbare websites naar HTTPS migreren. Als u uw privéserver niet naar HTTPS kunt migreren, kunt u met de nieuwe toestemmingspromptcontrole de controles op gemengde inhoud versoepelen.

Een typische workflow voor een verzoek om privénetwerktoegang met toestemmingsprompt is als volgt.

Activeer de toestemmingsprompt

Voeg het nieuwe kenmerk targetAddressSpace toe als ophaaloptie, waarna het verzoek de controle op gemengde inhoud kan overslaan.

fetch("http://router.local/ping", {
  targetAddressSpace: "private",
});

In overeenstemming met Private Network Access: preflights introduceren , wordt elk verzoek tot een particulier netwerk voorafgegaan door een preflightverzoek. Deze preflight-aanvraag bevat een nieuwe header, Access-Control-Request-Private-Network: true , en het bijbehorende antwoord moet de header Access-Control-Allow-Private-Network: true bevatten.

Om tegemoet te komen aan de nieuwe toestemmingsprompt moeten apparaten twee nieuwe antwoordheaders bevatten: Private-Network-Access-Name en Private-Network-Access-ID .

  • Private-Network-Access-ID : een 48-bits waarde weergegeven als 6 hexadecimale bytes, gescheiden door dubbele punten.
  • Private-Network-Access-Name : een geldige naam als tekenreeks die overeenkomt met de reguliere ECMAScript-expressie /^[a-z0-9_-.]+$/. De maximale lengte van de naam is 248 UTF-8-code-eenheden.
Private-Network-Access-Name: "My Smart Toothbrush"
Private-Network-Access-ID: "01:23:45:67:89:0A"

Demo

Je kunt de demo bekijken op: https://private-network-access-permission-test.glitch.me/ .

Om de demowebsite te kunnen gebruiken, moet u uw persoonlijke privéserver starten. De privéserver moet reageren met de HTTP-header Access-Control-Allow-Private-Network: true , samen met door de server opgegeven headers Private-Network-Access-ID en Private-Network-Access-Name . Als alles correct is ingesteld, zou de volgende toestemmingsprompt moeten verschijnen:

Sluit de proefperiode voor de beëindiging van de niet-beveiligde context af

Voor websites die Private Network Access hebben geregistreerd voor de beëindiging van de proefperiode voor niet-beveiligde contexten , is dit het moment om uw website te migreren met onze nieuwe toestemmingsprompt en de proefperiode nu af te sluiten.

Nadat u uw code heeft bijgewerkt, verwijdert u het proeftoken uit uw HTML-, JavaScript- of HTTP-headers. Als u niet meer weet waar u het proeftoken hebt geplaatst, raadpleegt u het gedeelte Registreren voor beëindiging van de proefperiode in het vorige blogbericht.

Mogelijk wilt u ook het token op de proefpagina verwijderen.

Wat is het volgende?

De oplossing voor verzoeken van niet-API fetch() wordt nog onderzocht.

Er zijn verschillende oplossingen getest, bijvoorbeeld door gebruik te maken van servicemedewerkers of het maken van doeladresruimte als een nieuw Content-Security-Policy. De uiteindelijke vorm voor verzoeken van niet-API fetch() wordt echter nog onderzocht.

Verzoeken van subframes kunnen in de toekomst mogelijk worden ondersteund met toestemmingsbeleid.

In de toekomst willen we mogelijk het toestemmingsbeleid ondersteunen om de mogelijkheid voor subframes te versoepelen.

Feedback voor gebruiksscenario's voor privénetwerken

Als u een website host op een particulier netwerk waarvoor verzoeken van openbare netwerken nodig zijn, wil het Chrome-team uw feedback! Dien een probleem in bij de Chromium Issue Tracker (component: Blink>SecurityFeature>CORS>PrivateNetworkAccess) of in de GitHub-repository .

Bronnen