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

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

Aktualizacje

• 7 lipca 2022 r.: zaktualizowaliśmy bieżący stan i dodano definicję przestrzeni 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

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

Chrome zacznie wysyłać żądanie procesu wstępnego CORS przed każdym żądaniem sieci prywatnej dotyczącym zasobu podrzędnego, które zawiera żądanie w celu uzyskania wyraźnego pozwolenia z serwera docelowego. To żądanie procesu wstępnego będą mieć nowy nagłówek, Access-Control-Request-Private-Network: true oraz musi mieć odpowiedni nagłówek, Access-Control-Allow-Private-Network: true

Ma to na celu ochronę użytkowników przed atakami polegającymi na sfałszowaniu żądania z innej witryny (CSRF). które są kierowane na routery i inne urządzenia w sieciach prywatnych. Te ataki objęły setki tysięcy użytkowników, co umożliwia hakerom przekierowywanie ich na szkodliwe serwery.

Plan wdrożenia

Chrome będzie wdrażać tę zmianę w 2 etapach, aby dać witrynom czas na to, i odpowiednio go dostosować.

1. W Chrome 104:

   • Eksperymenty w Chrome polegające na wysyłaniu żądań procesów wstępnych przed siecią prywatną żądania zasobów podrzędnych.
   • Błędy procesów wstępnych są wyświetlane tylko w Narzędziach deweloperskich, bez żadnych innych na żądania w sieci prywatnej.
   • Chrome zbiera dane o zgodności i kontaktuje się z największymi witryn.
   • Oczekujemy, że będzie ona ogólnie zgodna z istniejącymi witrynami.
   .
   Ostrzeżenie: aby ograniczyć wpływ na witryny, które nie obsługują jeszcze procesu wstępnego, czas oczekiwania jest ograniczony do 200 milisekund w Chrome 104. Ograniczenie to zastosowano w trybie ostrzegawczym. Specjalny limit czasu oczekiwania zostanie usunięty po włącz tryb wymuszania, przełączając opcję „Szacuj wyniki sieci prywatnej”. Dostęp do procesów wstępnych na „Włączone” w chrome://flags, a limit domyślny to 5 sek.

2. W Chrome 113 najwcześniej:

   • Rozpocznie się on tylko wtedy, gdy dane dotyczące zgodności wskazują, że aby takie zmiany były wystarczająco bezpieczne, i w razie potrzeby skontaktowaliśmy się bezpośrednio z nimi.
   • Chrome wymusza, że żądania procesu wstępnego muszą zakończyć się powodzeniem. W przeciwnym razie nie powiodą się prośby.
   • Okres próbny wycofywania zaczyna się o i jednocześnie umożliwić witrynom, których dotyczy ten etap, żądanie i przedłużenia terminu. Okres próbny potrwa co najmniej 6 miesięcy.

.

Uwaga: podjęto wcześniejszą próbę wdrożenia ostrzeżeń w Chrome 98 i Chrome 102, ogłoszono wcześniej w tym poście na blogu. Ta funkcja została wycofana po stabilności i wykryto problemy ze zgodnością. Wykryliśmy problemy z Chrome 104.

Co to jest dostęp przez sieć prywatną (PNA)

Dostęp do sieci prywatnej (dawniej CORS-RFC1918) ogranicza możliwość wysyłania żądań do serwerów przez witryny prywatne sieci.

Przeglądarka Chrome wdrożyła już część specyfikacji: od wersji 96 bezpieczne konteksty mogą wysyłać żądania sieciowe. Zapoznaj się z poprzednim poście na blogu.

Specyfikacja rozszerza też zasadę CORS. tak, aby witryny musiały od razu prosić o zezwolenie na dostęp do serwerów w sieciach prywatnych, zanim będą mogli wysyłać dowolne żądania.

Hasło kluczowe: żądania sieci prywatnej to żądania, których adres IP serwera docelowego to bardziej prywatne niż te, z których pochodzi inicjator żądania. Przykład: żądanie z witryny publicznej (https://example.com) do witryny prywatnej (http://router.local) lub żądanie z witryny prywatnej do lokalnego hosta.

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 IPv4 adresów pętli (127.0.0.0/8) zdefiniowane w sekcji 3.2.1.3 dokumentu RFC1122. lub adresów zapętlających się IPv6 (::1/128) zdefiniowane w sekcji 2.5.3 dokumentu RFC4291.

Prywatna przestrzeń adresów IP zawiera adresy IP o znaczeniu wyłącznie w bieżącej sieci, w tym 10.0.0.0/8, 172.16.0.0/12 oraz 192.168.0.0/16 zdefiniowane w dokumencie RFC1918, adresy lokalne linków 169.254.0.0/16 zdefiniowane w RFC3927, unikalne lokalne adresy e-mail IPv6 fc00::/7 zdefiniowane w dokumencie RFC4193, adresy pojedynczego połączenia IPv6 fe80::/10 zdefiniowane w sekcji 2.5.6 dokumentu RFC4291. i zmapowane na IPv4, gdzie zmapowany adres IPv4 sam jest prywatny.

Publiczna przestrzeń 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 jest uważany za bardziej prywatny niż publiczny adres IP.

Związek między publicznymi, prywatnymi i lokalnymi sieciami w sieci prywatnej Dostęp (CORS-RFC1918)

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

Żądania kontroli wstępnych

Tło

Żądania procesu wstępnego to mechanizm stosowany w ramach standardu CORS , aby zażądać zgody od witryny docelowej przed wysłaniem do niej żądania HTTP które mogą mieć efekty uboczne. Dzięki temu serwer docelowy będzie rozumieć protokołu CORS i znacznie zmniejsza ryzyko ataków CSRF.

Prośba o uprawnienia jest wysyłana jako żądanie HTTP OPTIONS z określonymi nagłówkami żądania CORS. opisujący zbliżające się żądanie HTTP. Odpowiedź musi zawierać określone nagłówki odpowiedzi CORS wyraźną akceptację nadchodzącego żądania.

Co nowego w funkcji Dostęp do sieci prywatnej

W przypadku żądań wstępnych jest wprowadzana nowa para nagłówków żądań i odpowiedzi:

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

Żądania procesu wstępnego do PNA są wysyłane w przypadku wszystkich żądań w sieci prywatnej, niezależnie od metody żądania oraz tryb. Są wysyłane przed żądaniami w trybie cors, a także w trybie no-cors i we wszystkich innych trybach. Ten ponieważ wszystkie żądania z sieci prywatnej mogą być wykorzystywane do ataków CSRF, niezależnie od trybu żądania i tego, czy treść odpowiedzi które są dostępne dla inicjatora.

Uwaga: jeśli żądanie sieci prywatnej jest wysyłane w trybie cors, nagłówki CORS muszą należy ustawić w końcowej odpowiedzi, oprócz odpowiedzi wstępnej.

Żą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ż adres inicjujący. To coś innego niż zwykłe CORS, gdzie żądania wstępne dotyczą tylko żądań z innych domen. Proces wstępny są chronione przed żądaniami z tego samego źródła, ataki rebindingu DNS.

Przykłady

Obserwowalne zachowanie zależy od: trybie żądania.

Tryb bez CORS

Powiedz, że umieszczone są elementy (https://foo.example/index.html) <img src="https://bar.example/cat.gif" alt="dancing cat"/> i Adres bar.example jest adresem 192.168.1.1, prywatnym adresem IP zgodnym z 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ć, podając:

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

Ostrzeżenie: serwer może ustawić wartość Access-Control-Allow-Origin: *, chociaż to jest niebezpieczne i odradzamy takie działania. Zasoby sieci prywatnej rzadko powinny być dostępne dla wszystkich należy więc przemyśleć ryzyko związane z ustawieniem takiego nagłówka.

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

HTTP/1.1 GET /cat.gif
...

Na które serwer może normalnie odpowiedzieć.

Tryb CORS

Powiedzmy, że https://foo.example/index.html uruchamia 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ć, podając:

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 wysyła właściwe żądanie:

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

Na które 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 wersji Chrome 104 w przypadku wykrycia żądania sieci prywatnej przed wysłaniem żądania. Jeśli to żądanie wstępne zakończy się niepowodzeniem, żądanie nadal zostanie wysłane, ale w Narzędziach deweloperskich pojawi się ostrzeżenie problemów.

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

Jeśli Twoje żądanie spowodowałoby uruchomienie standardowego procesu wstępnego CORS bez przez reguły dostępu do sieci prywatnej, w a pierwszy zawsze pokazuje błąd. To jest znanym błędzie. Możesz go bezpiecznie zignorować.

Aby sprawdzić, co się stanie, jeśli wyegzekwowano proces wstępny, możesz: przekaż ten argument wiersza poleceń: od Chrome 98:

--enable-features=PrivateNetworkAccessRespectPreflightResults

Każde nieudane żądanie procesu wstępnego spowoduje niepowodzenie pobierania. Dzięki temu możesz: aby sprawdzić, czy witryna będzie działać po drugiego etapu naszego planu wdrożenia. Błędy można zdiagnozować w w taki sam sposób jak w przypadku ostrzeżeń w panelach Narzędzi deweloperskich wspomnianych powyżej.

Co zrobić, gdy problem dotyczy Twojej witryny

Gdy ta zmiana zostanie wprowadzona w Chrome 104, witryny. Zdecydowanie zalecamy jednak zaktualizowanie ścieżek, których dotyczy problem, do aby zapewnić prawidłowe działanie witryny.

Dostępne są 2 rozwiązania:

1. Obsługuj żądania wstępne po stronie serwera
2. Wyłącz kontrole PNA za pomocą zasad przedsiębiorstwa

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

Zaktualizuj serwer docelowy wszystkich pobrań, których dotyczy problem, aby obsługiwać procesy wstępne PNA żądań. Najpierw zaimplementuj obsługę standardowych żądań procesów wstępnych CORS w tras, których to dotyczy. Następnie dodaj obsługę 2 nowych nagłówków odpowiedzi.

Gdy serwer odbiera żądanie wstępne (żądanie OPTIONS z CORS) ), serwer powinien sprawdzić, czy występuje Access-Control-Request-Private-Network: true. Jeśli ten nagłówek to w żądaniu, serwer powinien sprawdzić nagłówek Origin oraz żądania wraz z innymi istotnymi informacjami (takimi jak Access-Control-Request-Headers), aby sprawdzić, czy żądanie jest bezpieczne. Zwykle należy zezwolić na dostęp do jednego źródła pod Twoją kontrolą.

Ostrzeżenie: uważaj na niezabezpieczone źródła (nie https), ponieważ są nieuwierzytelnione. Na ścieżce osoba przeprowadzająca atak może podszywać się pod dowolne takie pochodzenie!

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

Konkretne scenariusze 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ć opcję Prywatny Dostęp do sieci jest sprawdzany przy użyciu 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 sieci prywatnej, która oczekuje żądań od sieci publicznych, zespół Chrome chciałby zapoznać się z Twoimi opiniami i przypadkami użycia. Daj nam znać, zgłaszając problem z Chromium na crbug.com i ustaw komponent do Blink>SecurityFeature>CORS>PrivateNetworkAccess.

Co dalej?

Teraz Chrome rozszerzy sprawdzanie dostępu do sieci prywatnej, aby obejmowały procesy internetowe: oddelegowanych, współdzielonych i współdzielonych pracowników. Wstępnie chcemy Chrome 107 zaczną wyświetlać ostrzeżenia.

Następnie Chrome rozszerzy sprawdzanie dostępu do sieci prywatnej na elementy nawigacyjne, włącznie z elementami iframe i wyskakującymi okienkami. Zamierzamy wprowadzić Chrome 108 wyświetlanie ostrzeżeń.

W obu przypadkach będziemy ostrożnie kontynuować wdrażanie etapowe, aby dać programistom stron internetowych czas na dostosowanie się i oszacowanie ryzyka związanego ze zgodnością.

Podziękowania

Zdjęcie na okładkę: Mark Olsen w: Odchylenie.