Kończy się okres próbny wycofywania niezabezpieczonych kontekstów (PNA) – zaimplementuj prośbę o przyznanie uprawnień PNA

Yifan Luo
Yifan Luo

Chrome 124 zawiera uprawnienie dostępu do sieci prywatnej, które umożliwia korzystanie z funkcji zrelaksowania zasad dotyczących treści mieszanych. W przypadku witryn, które potrzebują więcej czasu na przygotowanie się do tej zmiany, trwa okres próbny wycofywania. Wycofanie zakończy się wraz z wydaniem Chrome 132, co nastąpi 4 lutego 2025 r. Z tego posta dowiesz się więcej o zmianach, projekcie funkcji, migracji obecnych witryn oraz testowaniu wdrożenia.

Co się zmienia?

Aby nawiązywać połączenia z urządzeniami w sieci prywatnej, które nie mają globalnie unikalnych nazw i nie mogą więc uzyskać certyfikatów TLS, ta funkcja wprowadza nową opcję fetch(), która pozwala deweloperom określić zamiar nawiązywania połączenia z takim urządzeniem. Obejmuje to nową funkcję kontrolowaną przez zasady, która ogranicza dostęp do tej funkcji w przypadku każdej witryny, oraz nowe nagłówki w odpowiedzi preflight serwera, które zawierają dodatkowe metadane.

Czym jest dostęp z sieci prywatnej?

Dostęp do sieci prywatnej (PNA) to funkcja zabezpieczeń, która ogranicza możliwość wysyłania żądań przez witryny do serwerów w sieciach prywatnych. Pomaga to chronić użytkowników i sieci wewnętrzne przed potencjalnymi atakami, takimi jak ataki polegające na sfałszowaniu żądania z innej witryny (CSRF). Chrome stopniowo wdraża PNA, a w nadchodzących wersjach rozszerzymy ochronę.

Dlaczego wymagane jest wyświetlenie prośby o uprawnienia?

W Chrome 94 wprowadzono blokowanie dostępu do sieci prywatnej z niebezpiecznych publicznych witryn internetowych. Trwający test wycofywania dostępu do sieci prywatnej z kontekstów niezabezpieczonych wykazał trudności w przenoszeniu dotkniętych problemem witryn do HTTPS. Powszechnym problemem jest trudność migracji urządzeń prywatnych do HTTPS, co prowadzi do naruszenia zasad dotyczących treści mieszanych.

Aby rozwiązać ten problem, w ramach testów wersji origin w Chrome 120 oraz w wersji stabilnej od Chrome 124 dodano nowy monit o przyznaniu uprawnień.

Kiedy wymagane jest wyświetlenie prośby o uprawnienia?

Zaplanowaliśmy zakończenie testów wycofywania kontekstów niezabezpieczonych po wprowadzeniu funkcji prośby o przyznanie uprawnień. Aby zapewnić zgodność, musisz przenieść publiczne witryny do protokołu HTTPS. Jeśli nie możesz przenieść prywatnego serwera na HTTPS, nowa funkcja prośby o uprawnienia pozwoli Ci zaniechać sprawdzania treści mieszanych.

Typowy przepływ pracy w przypadku żądania dostępu do sieci prywatnej z wyświetleniem prośby o uprawnienia wygląda tak:

Wywołanie okna z prośbą o uprawnienia

Dodaj nowy atrybut targetAddressSpace jako opcję pobierania, a żądanie może pominąć sprawdzanie treści mieszanych.

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

Zgodnie z artykułem Dostęp z sieci prywatnej: wprowadzenie kontroli wstępnej każda prośba dotycząca sieci prywatnej poprzedzona jest żądaniem wstępnym. To żądanie wstępne będzie zawierać nowy nagłówek Access-Control-Request-Private-Network: true, a odpowiednia odpowiedź musi zawierać nagłówek Access-Control-Allow-Private-Network: true.

Aby obsługiwać nowe żądanie uprawnień, urządzenia muszą zawierać 2 nowe nagłówki odpowiedzi: Private-Network-Access-NamePrivate-Network-Access-ID.

  • Private-Network-Access-ID: 48-bitowa wartość przedstawiona jako 6 bajtów szesnastkowych rozdzielonych dwukropkami.
  • Private-Network-Access-Name: prawidłowa nazwa jako ciąg znaków, który pasuje do wyrażenia regularnego ECMAScript /^[a-z0-9_-.]+$/.. Maksymalna długość nazwy to 248 jednostek kodu UTF-8.
Private-Network-Access-Name: "My Smart Toothbrush"
Private-Network-Access-ID: "01:23:45:67:89:0A"

Prezentacja

Demo możesz sprawdzić na stronie https://private-network-access-permission-test.glitch.me/.

Aby korzystać z witryny demonstracyjnej, musisz uruchomić swój prywatny serwer. Serwer prywatny powinien odpowiadać nagłówkiem HTTP Access-Control-Allow-Private-Network: true oraz nagłówkami Private-Network-Access-ID i Private-Network-Access-Name określonymi przez serwer. Jeśli wszystko jest prawidłowo skonfigurowane, powinien pojawić się taki komunikat z prośbą o uprawnienia:

Zakończenie okresu próbnego wycofywania niebezpiecznego kontekstu

W przypadku witryn, które zarejestrowały się w ramach testu wersji 2.0 Private Network Access w niebezpiecznych kontekstach, nadszedł czas na migrację witryny z nową prośbą o uprawnienia i zakończenie testu.

Po zaktualizowaniu kodu usuń token wersji próbnej w nagłówkach HTML, JavaScript lub HTTP. Jeśli nie pamiętasz, gdzie znajduje się token wersji próbnej, zapoznaj się z sekcją Rejestracja w wersji próbnej wycofywanej usługi w poprzednim poście na blogu.

Możesz też usunąć token na stronie z informacjami o testach wersji próbnej.

Co dalej?

Rozwiązanie dotyczące żądań z źródeł innych niż interfejs API fetch() jest nadal testowane.

Przetestowano kilka rozwiązań, na przykład użycie usług workerów lub utworzenie przestrzeni adresów docelowych jako nowej polityki Content-Security-Policy. Jednak ostateczny kształt żądań wysyłanych z usług innych niż API fetch() jest nadal analizowany.

W przyszłości prośby z ramek podrzędnych mogą być obsługiwane w ramach zasad dotyczących uprawnień.

W przyszłości możemy wprowadzić zasady dotyczące uprawnień, aby rozszerzyć możliwości korzystania z podramek.

Opinie dotyczące zastosowań sieci prywatnych

Jeśli hostujesz witrynę w sieci prywatnej, która potrzebuje żądań z sieci publicznej, zespół Chrome chce poznać Twoją opinię. Zgłoś problem w śledzeniu błędów Chromium (komponent: Blink>SecurityFeature>CORS>PrivateNetworkAccess) lub w repozytorium GitHub.

Zasoby