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 testowy wycofywania. Testy te zakończą 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 fałszowanie żądań w różnych witrynach (CSRF). Chrome stopniowo wdraża PNA, a w nadchodzących wersjach rozszerzy 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 na HTTPS, co prowadzi do naruszenia zasad dotyczących treści mieszanych.
Aby rozwiązać ten problem, w Chrome 120 dodaliśmy nowy monit o pozwoleniu w ramach testowania origin, a w Chrome 124 – w wersji stabilnej.
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 o dostęp z 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 można było uwzględnić prośbę o nowe uprawnienia, urządzenia muszą zawierać 2 nowe nagłówki odpowiedzi: Private-Network-Access-Name i Private-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
Możesz ją wypróbować 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 wyświetlić się ten komunikat z prośbą o uprawnienia:
Wyjście z 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 z nagłówków 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 subskrypcji próbnej.
Co dalej?
Rozwiązanie dotyczące żądań z źródeł innych niż interfejs API fetch() jest nadal testowane.
Przetestowano kilka rozwiązań, m.in. za pomocą mechanizmów Service Worker lub utworzenia docelowej przestrzeni adresowej jako nowej zasady Content-Security-Policy. Jednak ostateczny kształt żądań wysyłanych z usług innych niż API fetch() jest nadal analizowany.
W przyszłości żądania 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 na temat przypadków użycia sieci prywatnej
Jeśli hostujesz witrynę w sieci prywatnej, która wymaga żądań z sieci publicznych, zespół Chrome czeka na Twoją opinię. Zgłoś problem w śledzeniu błędów Chromium (komponent: Blink>SecurityFeature>CORS>PrivateNetworkAccess) lub w repozytorium GitHub.