Der Test für den privaten Netzwerkzugriff (PNA) für unsichere Kontexte wird beendet – implementieren Sie die PNA-Berechtigungsaufforderung

Yifan Luo
Yifan Luo
GitHub

Chrome 124 enthält die Funktion Zugriff auf private Netzwerke, um die Einschränkungen für gemischte Inhalte zu lockern. Für Websites, die mehr Zeit für die Vorbereitung auf diese Änderung benötigen, läuft derzeit ein Test zur Einstellung. Dieser Test endet jedoch mit Chrome 132, der voraussichtlich am 4. Februar 2025 veröffentlicht wird. In diesem Beitrag wird die Änderung erläutert. Außerdem erfährst du mehr über das Design der Funktion, wie du deine aktuellen Websites migrierst und wie du deine Implementierung testest.

Was ändert sich?

Um Verbindungen zu Geräten in einem privaten Netzwerk herzustellen, die keine global eindeutigen Namen haben und daher keine TLS-Zertifikate erhalten können, wird mit dieser Funktion eine neue Option in fetch() eingeführt, mit der Entwickler ihre Absicht erklären können, mit einem solchen Gerät zu kommunizieren. Dazu gehören eine neue richtliniengesteuerte Funktion, mit der der Zugriff auf diese Funktion für jede Website gesteuert wird, und neue Header für die Preflight-Antwort des Servers, um zusätzliche Metadaten bereitzustellen.

Was ist der private Netzwerkzugriff?

Private Network Access (PNA, ehemals CORS-RFC1918 und kurz als „Local Network Access“) ist ein Sicherheitsfeature, das die Fähigkeit von Websites einschränkt, Anfragen an Server in privaten Netzwerken zu senden. So werden Nutzer und interne Netzwerke vor potenziellen Angriffen wie Cross-Site Request Forgery (CSRF) geschützt. In Chrome wird PNA nach und nach implementiert. In zukünftigen Releases wird der Schutz erweitert.

Warum ist eine Berechtigungsaufforderung erforderlich?

In Chrome 94 wurde der Zugriff auf private Netzwerke von nicht sicheren öffentlichen Websites blockiert. Der laufende Test zur Einstellung des privaten Netzwerkzugriffs aus nicht sicheren Kontexten hat Probleme bei der Migration betroffener Websites zu HTTPS aufgedeckt. Ein häufiger Grund ist die Schwierigkeit, private Geräte zu HTTPS zu migrieren, was zu Verstößen bei der gemischten Inhaltsprüfung führt.

Um diese Herausforderung zu bewältigen, wurde in Chrome 120 im Rahmen eines Ursprungstests und in Chrome 124 in der stabilen Version ein neuer Berechtigungsaufforderung hinzugefügt.

Wann ist eine Berechtigungsanfrage erforderlich?

Wir hatten vor, den Test zur Einstellung unsicherer Kontexte einige Meilensteine zu beenden, nachdem die Funktion zur Berechtigungsaufforderung verfügbar war. Zur Gewährleistung der Kompatibilität müssen Sie Ihre öffentlichen Websites zu HTTPS migrieren. Wenn Sie Ihren privaten Server nicht zu HTTPS migrieren können, können Sie mit der neuen Funktion für Berechtigungsaufforderungen die Prüfung auf gemischte Inhalte lockern.

Ein typischer Workflow für eine Anfrage zum Zugriff auf ein privates Netzwerk mit Berechtigungsaufforderung sieht so aus:

Berechtigungsaufforderung auslösen

Fügen Sie das neue targetAddressSpace-Attribut als Abrufoption hinzu. Dann kann die Anfrage die Prüfung auf gemischte Inhalte überspringen.

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

Gemäß den Vorgaben unter Private Network Access: Introduction preflights wird jeder privaten Netzwerkanfrage eine Preflight-Anfrage vorangestellt. Diese Preflight-Anfrage enthält den neuen Header Access-Control-Request-Private-Network: true. Die entsprechende Antwort muss den Header Access-Control-Allow-Private-Network: true enthalten.

Für die neue Berechtigungsanfrage müssen Geräte zwei neue Antwortheader enthalten: Private-Network-Access-Name und Private-Network-Access-ID.

  • Private-Network-Access-ID: Ein 48-Bit-Wert, dargestellt als 6 hexadezimale Byte, getrennt durch Doppelpunkte.
  • Private-Network-Access-Name: Ein gültiger Name als String, der mit dem ECMAScript-regulären Ausdruck /^[a-z0-9_-.]+$/. übereinstimmt. Die maximale Länge des Namens beträgt 248 UTF-8-Codeeinheiten.
Private-Network-Access-Name: "My Smart Toothbrush"
Private-Network-Access-ID: "01:23:45:67:89:0A"

Demo

Sie können sich die Demo unter https://private-network-access-permission-test.glitch.me/ ansehen.

Sie müssen Ihren persönlichen privaten Server starten, um die Demowebsite verwenden zu können. Der private Server sollte mit dem HTTP-Header Access-Control-Allow-Private-Network: true sowie den vom Server angegebenen Headern Private-Network-Access-ID und Private-Network-Access-Name antworten. Wenn alles richtig eingerichtet ist, sollte die folgende Berechtigungsanfrage angezeigt werden:

Testzeitraum für die Einstellung von nicht sicheren Kontexten beenden

Für Websites, für die der Test zur Einstellung des privaten Netzwerkzugriffs für nicht sichere Kontexte registriert wurde, ist es jetzt an der Zeit, Ihre Website mithilfe der neuen Berechtigungsanfrage zu migrieren und den Test zu beenden.

Löschen Sie nach der Aktualisierung des Codes das Testtoken aus Ihren HTML-, JavaScript- oder HTTP-Headern. Wenn Sie nicht mehr wissen, wo Sie das Testtoken abgelegt haben, lesen Sie den Abschnitt Für den Test zur Einstellung registrieren im vorherigen Blogpost.

Sie können auch das Token auf der Testseite löschen.

Nächste Schritte

Eine Lösung für Anfragen von fetch(), die nicht über die API erfolgen, wird derzeit geprüft.

Es wurden mehrere Lösungen getestet, z. B. die Verwendung von Dienstmitarbeitern oder die Verwendung des Zieladressraums als neue Content-Security-Policy. Die endgültige Form für Anfragen von fetch(), die nicht über die API erfolgen, wird jedoch noch untersucht.

Anfragen von untergeordneten Frames werden möglicherweise in Zukunft mit einer Berechtigungsrichtlinie unterstützt.

Zukünftig möchten wir möglicherweise Berechtigungsrichtlinien unterstützen, um die Möglichkeiten für Subframes zu lockern.

Feedback zu Anwendungsfällen für private Netzwerke

Wenn Sie eine Website in einem privaten Netzwerk hosten, für die Anfragen von öffentlichen Netzwerken erforderlich sind, würde das Chrome-Team gerne Ihr Feedback hören. Melden Sie das Problem im Chromium-Issue-Tracker (Komponente: Blink > SecurityFeature > CORS > PrivateNetworkAccess) oder im GitHub-Repository.

Ressourcen