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 gemischte Inhalte zuzulassen. 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 erfahren Sie mehr über die Änderung, das Design der Funktion, die Migration Ihrer aktuellen Websites und die Implementierung.

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?

Der private Netzwerkzugriff (Private Network Access, PNA, früher CORS-RFC1918 und kurz Local Network Access) ist eine Sicherheitsfunktion, die die Möglichkeit 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. Der Schutz wird in zukünftigen Releases erweitert.

Warum ist eine Berechtigungsanfrage erforderlich?

In Chrome 94 wurde der Zugriff auf private Netzwerke von nicht sicheren öffentlichen Websites blockiert. Die laufende Testphase zur Einstellung des Zugriffs auf private Netzwerke aus nicht sicheren Kontexten hat Herausforderungen bei der Migration betroffener Websites zu HTTPS aufgedeckt. Ein häufiges Problem ist die Schwierigkeit, private Geräte zu HTTPS zu migrieren, was zu Verstößen bei der Prüfung auf gemischte Inhalte 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 geplant, die Testphase für die Einstellung von nicht sicheren Kontexten einige Meilensteine nach der Einführung der Berechtigungsanfrage zu beenden. Um für Kompatibilität zu sorgen, 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äß dem Artikel Privater Netzwerkzugriff: Einführung von Preflights geht jeder Anfrage an ein privates Netzwerk eine Preflight-Anfrage voraus. Diese Preflight-Anfrage enthält einen neuen Header, Access-Control-Request-Private-Network: true, und 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, der als sechs Hexadezimalbytes dargestellt wird, die durch Doppelpunkte getrennt sind.
  • 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 die Testversion zur Einstellung des privaten Netzwerkzugriffs für nicht sichere Kontexte registriert wurde, ist es jetzt an der Zeit, Ihre Website mithilfe unserer neuen Berechtigungsanfrage zu migrieren und die Testversion 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 das Token auch 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 Definition 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.

In Zukunft möchten wir möglicherweise Berechtigungsrichtlinien unterstützen, um die Verwendung von 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. Reichen Sie ein Problem im Chromium-Issue-Tracker (Komponente: Blink> SecurityFeature> CORS> PrivateNetworkAccess) oder im GitHub-Repository ein.

Ressourcen