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

Yifan Luo
Yifan Luo
GitHub

Chrome 124 obejmuje uprawnienie Dostęp do sieci prywatnej w celu złagodzenia treści mieszanych. W przypadku witryn, które potrzebują więcej czasu na przygotowanie się do tej zmiany, trwa próba wycofywania. Zakończy się on jednak od wersji Chrome 126, która powinna zostać udostępniona 4 września 2024 r. W tym poście opisujemy tę zmianę oraz omawiamy wygląd tej funkcji, sposoby przenoszenia obecnych witryn i testowanie implementacji.

Co się zmienia?

Aby umożliwić nawiązywanie połączeń z urządzeniami w sieci prywatnej, które nie mają globalnych nazw, a tym samym nie mogą uzyskać certyfikatów TLS, ta funkcja wprowadza w fetch() nową opcję deklarowania zamiaru dewelopera rozmowy z takim urządzeniem. Obejmuje to nową, kontrolowaną przez zasady funkcję, która blokuje dostęp każdej witryny do tej możliwości, oraz nowe nagłówki odpowiedzi procesu wstępnego serwera, które zawierają dodatkowe metadane.

Co to jest dostęp do sieci prywatnej?

Dostęp do sieci prywatnej (PNA, dawniej CORS-RFC1918, w skrócie Dostęp do sieci lokalnej) to funkcja zabezpieczeń, która ogranicza możliwość wysyłania przez witryny żądań do serwerów w sieciach prywatnych. Pomaga to chronić użytkowników i sieci wewnętrzne przed potencjalnymi atakami, takimi jak fałszywe żądania między witrynami (CSRF). Stopniowo wdrażamy PNA w Chrome, a w kolejnych wersjach zwiększymy bezpieczeństwo.

Dlaczego potrzebna jest prośba o przyznanie uprawnień?

W Chrome 94 blokować dostęp z niezabezpieczonych witryn publicznych z sieci prywatnej. Trwający okres próbny wycofywania dostępu do sieci prywatnej z niezabezpieczonych kontekstów ujawnił wyzwania związane z przenoszeniem witryn, których dotyczy problem, do protokołu HTTPS. Częstym problemem jest migracja urządzeń prywatnych do protokołu HTTPS, co prowadzi do naruszenia zasad dotyczących różnych wersji treści.

Aby sprostać temu wyzwaniu, w okresie próbnym źródła w Chrome 120 oraz w stabilnej wersji Chrome 124 została dodana nowa prośba o przyznanie uprawnień.

Kiedy potrzebna jest prośba o przyznanie uprawnień?

Zamierzaliśmy zakończyć okres próbny wycofywania niezabezpieczonych kontekstów kilka minut po udostępnieniu funkcji próśb o przyznanie uprawnień. Aby zapewnić zgodność, musisz przenieść swoje witryny publiczne do HTTPS. Jeśli nie możesz przenieść serwera prywatnego do HTTPS, nowa funkcja próśb o uprawnienia pozwoli Ci złagodzić testy mieszanej treści.

Typowy przepływ pracy w przypadku żądania dostępu do sieci prywatnej z prośbą o przyznanie uprawnień wygląda tak.

Aktywuj prośbę o przyznanie uprawnień

Dodaj nowy atrybut targetAddressSpace jako opcję pobierania, dzięki czemu żądanie może pominąć sprawdzanie treści mieszanej.

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

Zgodnie z zasadą Dostęp do sieci prywatnej: wprowadzenie procesów wstępnych każde żądanie sieci prywatnej jest poprzedzone żądaniem procesu wstępnego. To żądanie procesu wstępnego będzie zawierać nowy nagłówek Access-Control-Request-Private-Network: true, a odpowiadająca mu odpowiedź musi zawierać nagłówek Access-Control-Allow-Private-Network: true.

Aby dostosować się do nowej prośby o przyznanie uprawnień, 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ść składająca się z 6 bajtów szesnastkowych rozdzielonych dwukropkiem.
  • Private-Network-Access-Name: prawidłowa nazwa jako ciąg znaków pasująca 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"

Pokaz

Tę wersję demo znajdziesz na stronie https://private-network-access-permission-test.glitch.me/.

Aby korzystać ze strony demonstracyjnej, musisz uruchomić osobisty serwer prywatny. Serwer prywatny powinien w odpowiedzi podać nagłówek HTTP Access-Control-Allow-Private-Network: true wraz z nagłówkami Private-Network-Access-ID i Private-Network-Access-Name określonymi przez serwer. Jeśli wszystko jest skonfigurowane prawidłowo, powinna wyświetlić się prośba o przyznanie uprawnień:

Zakończ okres próbny wycofywania niezabezpieczonego kontekstu

W przypadku witryn, które zarejestrowały próbę wycofania dostępu do sieci prywatnej na potrzeby niezabezpieczonych kontekstów, możesz przenieść witrynę z nową prośbą o przyznanie uprawnień i zamknąć okres próbny.

Po zaktualizowaniu kodu usuń token próbny z nagłówków HTML, JavaScript lub HTTP. Jeśli nie pamiętasz, gdzie został umieszczony token próbny, zajrzyj do sekcji Rejestracja w celu wycofania tokenów próbnych w poprzednim poście na blogu.

Token możesz też usunąć na stronie wersji próbnej.

Co dalej?

Rozwiązanie dotyczące żądań z elementu fetch() spoza interfejsu API jest nadal w trakcie opracowywania.

Przetestowaliśmy kilka rozwiązań, takich jak mechanizmy Service Worker czy utworzenie docelowej przestrzeni adresowej jako nowej zasady Content-Security-Policy. Ostateczny kształt żądań z fetch() spoza interfejsu API nadal jest w trakcie sprawdzania.

W przyszłości żądania z ramek podrzędnych mogą być obsługiwane za pomocą zasad dotyczących uprawnień.

W przyszłości możemy wprowadzić obsługę zasad dotyczących uprawnień, aby złagodzić możliwość korzystania z ramek podrzędnych.

Opinia na temat przypadków użycia sieci prywatnej

Jeśli hostujesz witrynę w sieci prywatnej, która wymaga żądań z sieci publicznych, zespół Chrome potrzebuje Twojej opinii. Zgłoś problem w narzędziu Chromium Issue Tracker (komponent: Blink>SecurityFeature>CORS>PrivateNetworkAccess) lub w repozytorium GitHub.

Zasoby