Dostęp do sieci prywatnej: wprowadzenie procesów wstępnych

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

Nowości

• 7 lipca 2022 r.: zaktualizowano bieżący stan i dodano definicję zakresu adresów IP.
• 27 kwietnia 2022 roku: zaktualizowaliśmy ogłoszenie dotyczące osi czasu.
• 7 marca 2022 r.: ogłosiliśmy wycofanie zmian po wykryciu problemów w Chrome 98.

Wprowadzenie

W ramach specyfikacji dostępu do sieci prywatnej (PNA) Chrome wycofuje bezpośredni dostęp do punktów końcowych sieci prywatnej z publicznych witryn internetowych.

Chrome zacznie wysyłać żądanie procesu wstępnego CORS przed każdym żądaniem sieci prywatnej dotyczącym zasobu podrzędnego, które prosi o wyraźne pozwolenie z serwera docelowego. To żądanie wstępne będzie zawierać nowy nagłówek Access-Control-Request-Private-Network: true, a odpowiednia odpowiedź będzie zawierać nagłówek Access-Control-Allow-Private-Network: true.

Celem jest ochrona użytkowników przed atakami polegającymi na fałszowaniu żądań między witrynami (CSRF), które mają na celu routery i inne urządzenia w sieciach prywatnych. Te ataki dotknęły setki tysięcy użytkowników, którzy zostali przekierowani na złośliwe serwery.

Plan wdrożenia

Chrome wprowadzi tę zmianę w 2 fazach, aby dać witrynom czas na zauważenie zmiany i dostosowanie się do niej.

1. W Chrome 104:

   • Eksperymenty w Chrome polegają na wysyłaniu żądań wstępnych przed żądaniami zasobów podrzędnych sieci prywatnej.
   • Błędy w sprawdzaniu wstępnym wyświetlają tylko ostrzeżenia w Narzędziach dla deweloperów, nie wpływając w żaden inny sposób na żądania sieci prywatnej.
   • Chrome zbiera dane o zgodności i kontaktuje się z największymi dotkniętymi problemem stronami internetowymi.
   • Oczekujemy, że będzie ona w dużej mierze kompatybilna z dotychczasowymi witrynami.

2. W Chrome 113 lub nowszej wersji:

   • Rozpoczniemy to tylko, jeśli dane dotyczące zgodności wskażą, że zmiana jest wystarczająco bezpieczna, a w razie potrzeby skontaktujemy się z Tobą bezpośrednio.
   • Chrome wymusza, aby żądania wstępne muszą zakończyć się powodzeniem. W przeciwnym razie żądania te kończą się niepowodzeniem.
   • Okres próbny wycofywania rozpoczyna się w tym samym czasie, aby umożliwić witrynom, których dotyczy ten etap, zgłoszenie prośby o wydłużenie czasu. Wersja próbna będzie dostępna przez co najmniej 6 miesięcy.

Co to jest dostęp z sieci prywatnej (PNA)

Prywatny dostęp do sieci (dawniej CORS-RFC1918) ogranicza możliwość wysyłania żądań do serwerów w sieciach prywatnych.

Chrome wdrożył już część specyfikacji: od wersji 96 Chrome tylko konteksty niezabezpieczone mogą wysyłać żądania sieci prywatnych. Więcej informacji znajdziesz w poprzednim poście na blogu.

Specyfikacja rozszerza też protokół współdzielenia zasobów między serwerami (CORS) tak, że witryny muszą teraz wyraźnie żądać uwierzytelnienia od serwerów w sieciach prywatnych, zanim będą mogły wysyłać dowolne żądania.

Jak PNA klasyfikuje adresy IP i identyfikuje sieć prywatną

Adresy IP są podzielone na 3 przestrzenie adresów IP: – public – private – local

Lokalna przestrzeń adresów IP zawiera adresy IP, które są albo adresami pętli zwrotnej IPv4 (127.0.0.0/8) zdefiniowanymi w sekcji 3.2.1.3 dokumentu RFC1122, albo adresami pętli zwrotnej IPv6 (::1/128) zdefiniowanymi w sekcji 2.5.3 dokumentu RFC4291.

Prywatna przestrzeń adresów IP zawiera adresy IP, które mają znaczenie tylko w ramach bieżącej sieci, w tym 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16 zdefiniowane w RFC1918, adresy link-local 169.254.0.0/16 zdefiniowane w RFC3927, unikalne lokalne adresy unicastowe IPv6 fc00::/7 zdefiniowane w RFC4193, lokalne adresy unicastowe IPv6 fe80::/10 zdefiniowane w sekcji 2.5.6 RFC4291 oraz mapowane na IPv4 adresy IPv6, gdzie mapowany adres IPv4 jest sam w sobie prywatny.

Przestrzeń publicznych adresów IP zawiera wszystkie inne adresy, które nie zostały wymienione wcześniej.

Lokalny adres IP jest uważany za bardziej prywatny niż prywatny adres IP.

Więcej informacji znajdziesz w artykule Prośba o opinię: CORS dla sieci prywatnych (RFC1918).

Żądania procesu wstępnego

Tło

Żądania wstępne to mechanizm wprowadzony przez standard Cross-Origin Resource Sharing (CORS), który służy do uzyskiwania zgody witryny docelowej przed wysłaniem do niej żądania HTTP, które może mieć skutki uboczne. Dzięki temu serwer docelowy rozumie protokół CORS, co znacznie zmniejsza ryzyko ataków CSRF.

Prośba o pozwolenie jest wysyłana jako żądanie HTTP OPTIONS z określonymi nagłówkami żądania CORS, które opisują nadchodzące żądanie HTTP. Odpowiedź musi zawierać określone nagłówki odpowiedzi CORS, które wyraźnie wyrażają zgodę na nadchodzące żądanie.

Co nowego w dostępie z sieci prywatnej

W żądaniach wstępnych wprowadzono nową parę nagłówków żądania i odpowiedzi:

• Access-Control-Request-Private-Network: true jest ustawiony we wszystkich żądaniach procesu wstępnego PNA.
• Wartość Access-Control-Allow-Private-Network: true musi być ustawiona we wszystkich odpowiedziach wstępnych PNA

Żądania wstępne dotyczące PNA są wysyłane w przypadku wszystkich żądań w sieci prywatnej, niezależnie od metody i trybu żądania. Są one wysyłane przed żądaniami w trybie cors, a także w trybie no-cors i wszystkich innych trybach. Dzieje się tak, ponieważ wszystkie żądania w sieci prywatnej mogą być wykorzystywane do ataków CSRF, niezależnie od trybu żądania i od tego, czy treść odpowiedzi jest udostępniana inicjatorowi.

Żądania procesu wstępnego do PNA są też wysyłane w przypadku żądań z tego samego źródła, jeśli docelowy adres IP jest bardziej prywatny niż inicjator. W odróżnieniu od zwykłego mechanizmu CORS żądania wstępne są dostępne tylko w przypadku żądań między domenami. Żądania procesu wstępnego dla żądań z tej samej domeny chronią przed atakami typu rebinding DNS.

Przykłady

Obserwowalne zachowanie zależy od trybu żądania.

Tryb bez CORS

Załóżmy, że https://foo.example/index.html zawiera <img src="https://bar.example/cat.gif" alt="dancing cat"/>, a bar.example przekierowuje do 192.168.1.1, czyli prywatnego adresu IP zgodnie ze standardem RFC 1918.

Chrome najpierw wysyła żądanie procesu wstępnego:

HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true

Aby to żądanie zostało zrealizowane, serwer musi odpowiedzieć:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true

Następnie Chrome wysyła właściwe żądanie:

HTTP/1.1 GET /cat.gif
...

Serwer może na nie normalnie odpowiedzieć.

Tryb CORS

Załóżmy, że https://foo.example/index.html wykonuje ten kod:

await fetch('https://bar.example/delete-everything', {
  method: 'PUT',
  credentials: 'include',
})

Powtórzę, że adres bar.example zmienia się na 192.168.1.1.

Chrome najpierw wysyła żądanie procesu wstępnego:

HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true

Aby to żądanie zostało zrealizowane, serwer musi odpowiedzieć:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true

Następnie Chrome wyśle właściwe żądanie:

HTTP/1.1 PUT /delete-everything
Origin: https://foo.example

Serwer może odpowiedzieć zgodnie ze zwykłymi regułami CORS:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example

Jak sprawdzić, czy zmiana dotyczy Twojej witryny

Od Chrome 104, jeśli wykryto żądanie sieci prywatnej, przed nim zostanie wysłane żądanie wstępne. Jeśli to żądanie wstępne się nie powiedzie, ostateczne żądanie nadal zostanie wysłane, ale w panelu problemów w Narzędziach deweloperskich pojawi się ostrzeżenie.

Żądania wstępne, których to dotyczy, można też wyświetlić i diagnozować w panelu sieci:

Jeśli Twoje żądanie bez reguł dostępu do sieci prywatnej wywołałoby zwykły proces wstępny CORS, w panelu sieci mogą pojawić się 2 procesy wstępne, z których pierwszy zawsze będzie wyglądał na nieudany. To znany błąd, który możesz zignorować.

Aby sprawdzić, co się dzieje, gdy wymuszono powodzenie kontroli wstępnej, możesz przekazać ten argument wiersza poleceń:

--enable-features=PrivateNetworkAccessRespectPreflightResults

Każde nieudane żądanie wstępne spowoduje niepowodzenie pobierania. Dzięki temu możesz sprawdzić, czy Twoja witryna będzie działać po drugiej fazie naszego planu wdrażania. Błędy można diagnozować w taki sam sposób jak ostrzeżenia, korzystając z wymienionych wyżej paneli w Narzędziach deweloperskich.

Co zrobić, jeśli Twoja witryna jest dotknięta problemem

Po wprowadzeniu tej zmiany w Chrome 104 nie powinna ona zakłócać działania żadnej witryny. Zdecydowanie zalecamy jednak zaktualizowanie ścieżek żądań, których dotyczy problem, aby mieć pewność, że witryna będzie nadal działać zgodnie z oczekiwaniami.

Dostępne są 2 rozwiązania:

1. Obsługa żądań procesu wstępnego po stronie serwera
2. Wyłącz kontrole PNA za pomocą zasad przedsiębiorstwa

Obsługa żądań procesu wstępnego po stronie serwera

Zaktualizuj serwer docelowy wszystkich pobieranych danych, aby obsługiwać żądania wstępnej weryfikacji PNA. Najpierw wdrożyć obsługę standardowych żądań wstępnych CORS na dotkniętych trasach. Następnie dodaj obsługę 2 nowych nagłówków odpowiedzi.

Gdy serwer otrzyma żądanie wstępne (żądanie OPTIONS z nagłówkami CORS), powinien sprawdzić obecność nagłówka Access-Control-Request-Private-Network: true. Jeśli ten nagłówek występuje w żądaniu, serwer powinien sprawdzić nagłówek Origin i ścieżkę żądania oraz wszelkie inne istotne informacje (na przykład Access-Control-Request-Headers), aby upewnić się, że żądanie jest bezpieczne. Zwykle należy zezwolić na dostęp do pojedynczego źródła, które jest pod Twoją kontrolą.

Gdy serwer zezwoli na żądanie, powinien w odpowiedzi 204 No Content (lub 200 OK) podać niezbędne nagłówki CORS i nowy nagłówek PNA. Te nagłówki to Access-Control-Allow-Origin i Access-Control-Allow-Private-Network: true, a także inne w razie potrzeby.

Więcej informacji o konkretnych scenariuszach znajdziesz w przykładach.

Wyłączanie sprawdzania dostępu do sieci prywatnej przy użyciu zasad firmowych

Jeśli masz kontrolę administracyjną nad użytkownikami, możesz wyłączyć prywatne kontrole dostępu do sieci, używając jednej z tych zasad:

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

Więcej informacji znajdziesz w artykule Omówienie zarządzania zasadami Chrome.

Prześlij nam opinię

Jeśli hostujesz witrynę w ramach sieci prywatnej, która oczekuje żądań z sieci publicznych, zespół Chrome chętnie pozna Twoją opinię i przypadki użycia. Daj nam znać, zgłaszając problem w Chromium na crbug.com i ustawiając komponent na Blink>SecurityFeature>CORS>PrivateNetworkAccess.

Co dalej?

Następnie Chrome rozszerzy sprawdzanie dostępu do sieci prywatnej na pracowników sieciowych, czyli tzw. pracowników „dedykowanych” i współdzielonych oraz pracowników usługi. Zamierzamy zacząć wyświetlać ostrzeżenia w Chrome 107.

Następnie Chrome rozszerzy weryfikację dostępu do sieci prywatnej, aby obejmowała nawigację, w tym iframe i okienka. Zamierzamy wstępnie zacząć wyświetlać ostrzeżenia w Chrome 108.

W obu przypadkach będziemy postępować ostrożnie, wprowadzając zmiany stopniowo, aby dać deweloperom stron internetowych czas na dostosowanie się do nich i oszacowanie ryzyka związanego z kompatybilnością.

Podziękowania

Zdjęcie główne: Mark Olsen na Unsplash.