Aktualizacje
23 marca 2023 r.: zaktualizowaliśmy oś czasu. Wycofanie funkcji nastąpi dopiero po aktualizacji Chrome 117.
19 stycznia 2023 r.: zaktualizowaliśmy oś czasu. Wycofanie funkcji nastąpi dopiero w wersji Chrome 114.
12 sierpnia 2022 r.: zaktualizowaliśmy harmonogram. Wycofanie nastąpi dopiero po aktualizacji Chrome 109.
10 lutego 2022 roku: w artykule Dostęp do sieci prywatnej: wprowadzenie procesów wstępnych
25 sierpnia 2021 roku: zaktualizowaliśmy ogłoszenie na osi czasu i wprowadziliśmy wersję próbną wycofywania.
W ramach specyfikacji dostępu do sieci prywatnej Chrome wycofuje dostęp z niezabezpieczonych witryn do punktów końcowych sieci prywatnej. Ma to na celu ochronę użytkowników przed atakami polegającymi na sfałszowaniu żądania z innych witryn (CSRF), które są wymierzone w routery i inne urządzenia w sieciach prywatnych. Takie ataki obejmowały setki tysięcy użytkowników, umożliwiając hakerom przekierowanie ich na złośliwe serwery.
W Chrome wprowadzimy te zmiany:
- Blokowanie żądań do sieci prywatnych z niezabezpieczonych witryn publicznych od Chrome 94.
- Przedstawiamy okres próbny wycofania, który zakończy się w Chrome.
- Umożliwi to deweloperom przesłanie prośby o przedłużenie terminu w przypadku wybranych źródeł, co nie będzie miało wpływu na okres próbny wycofywania.
- Wprowadzamy zasadę Chrome, która umożliwi zarządzanym wdrożeniam Chrome trwałe obejście wycofania starszej wersji. Dostępne w Chrome 92.
Jeśli potrzebujesz więcej czasu na złagodzenie wpływu rejestru wycofywania w okresie próbnym,
Jeśli masz kontrolę administracyjną nad użytkownikami, możesz ponownie włączyć tę funkcję za pomocą zasad Chrome.
Aby ograniczyć wpływ nowych ograniczeń, skorzystaj z jednej z tych strategii:
- Uaktualnij witrynę do protokołu HTTPS, a w razie potrzeby przejdź na serwer docelowy.
- Uaktualnij witrynę do protokołu HTTPS i używaj WebTransport.
- Odwrócić relację umieszczania.
Oś czasu
- Listopad 2020 r.: poproś o opinie na temat nadchodzących zmian.
- Marzec 2021 r.: po zapoznaniu się z opiniami i rozpoczęciu komunikacji ogłaszamy wprowadzenie zmian. Nazwa specyfikacji została zmieniona z CORS-RFC1918 na dostęp do sieci prywatnej.
- Kwiecień 2021 roku: wdrażamy Chrome 90 w wersji stabilnej i wyświetlają się ostrzeżenia o wycofaniu.
- Czerwiec 2021 r.: wdrażamy Chrome 92 w wersji beta i uniemożliwiamy blokowanie żądań z sieci prywatnej z niezabezpieczonych kontekstów. Ze względu na opinie deweloperów, którzy poprosili o więcej czasu na dostosowanie, wycofanie obsługi zostaje przeniesione do Chrome 93 i wraz z okresem próbnym.
- Lipiec 2021 r.: na podstawie opinii deweloperów zdecydowaliśmy, że wycofanie aplikacji i powiązany z nią okres próbny zostaną przeniesione do Chrome 94. Wycofanie funkcji nie będzie też miało wpływu na witryny prywatne.
- Sierpień 2021 roku: wprowadzamy Chrome 94 w wersji beta. Programiści stron internetowych mogą zarejestrować się w okresie próbnym wycofywania.
- Wrzesień 2021 roku: Chrome 94 trafia do wersji stabilnej. Deweloperzy stron internetowych powinni skorzystać z okresu próbnego wycofywania i wdrożyć tokeny próbne w środowisku produkcyjnym.
- Grudzień 2022 r.: wysłano ankietę dotyczącą testowania origin i otrzymano opinię. Rozszerzyliśmy okres próbny wycofywania do Chrome 113.
- Marzec 2023 roku: wydłużyliśmy okres próbny wycofywania do Chrome 116 i zakończy się on w Chrome 117. Pracujemy nad alternatywnym mechanizmem działającym na podstawie uprawnień, który będzie kierowany na pierwszą wersję Chrome 114.
- Maj 2023 r. (wstępnie): mechanizm oparty na uprawnieniach zostanie wdrożony w Chrome 114. Witryny mogą używać go do zakończenia okresu próbnego wycofywania.
- Wrzesień 2023 roku: wdrażanie Chrome 117 w wersji stabilnej kończy się okresem próbnym. Chrome blokuje wszystkie żądania sieci prywatnej pochodzące z publicznych, niezabezpieczonych kontekstów.
Co to jest dostęp do sieci prywatnej
Dostęp do sieci prywatnej (dawniej znany jako CORS-RFC1918) ogranicza możliwość wysyłania przez witryny żądań do serwerów w sieciach prywatnych. Zezwala na takie żądania tylko z bezpiecznych kontekstów. Specyfikacja rozszerza też protokół CORS, tak aby witryny mogły wysyłać dowolne żądania dopiero po jawnym żądaniu uwierzytelnienia przez serwery w sieciach prywatnych.
Żądania sieci prywatnej to żądania, których adres IP serwera docelowego jest bardziej prywatny niż ten, z którego pobrano inicjatora żądań. Na przykład żądanie z witryny publicznej (https://example.com) do witryny prywatnej (http://router.local) lub z witryny prywatnej do lokalnego hosta.
Więcej informacji znajdziesz w artykule na temat wymagania opinii: CORS dla sieci prywatnych (RFC1918).
Co to jest okres próbny wycofywania
Okresy próbne wycofania (wcześniej znane jako „testy odwrotnego pochodzenia)” to forma testów origin, która ułatwia wycofanie funkcji internetowych. Okresy próbne wycofania umożliwiają Chrome wycofanie pewnych funkcji internetowych i uniemożliwienie witrynom tworzenia nowych zależności, a jednocześnie dasz obecnym witrynom zależnym dodatkowy czas na ich migrację.
Podczas okresu próbnego wycofywane funkcje są domyślnie niedostępne dla wszystkich witryn. Deweloperzy, którzy nadal muszą korzystać z tych funkcji, muszą zarejestrować się w okresie próbnym wycofywania i uzyskać tokeny dla określonych źródeł stron internetowych, a następnie zmodyfikować swoje witryny tak, aby udostępniały je w nagłówkach HTTP lub metatagach (poza tym w tym przypadku). Jeśli witryna udostępnia prawidłowe tokeny pasujące do ich źródła, Chrome będzie zezwalać na używanie wycofanej funkcji przez ograniczony czas.
Więcej informacji znajdziesz w artykule Pierwsze kroki z testami origin Chrome i przewodnikiem po testach origin w Chrome dla programistów internetowych.
Co się zmienia w Chrome
Chrome 94
Od wersji Chrome 94 nie zezwalamy na wysyłanie żądań do sieci prywatnej z publicznych, niezabezpieczonych kontekstów (zwykle z witryn, które nie są dostarczane przez HTTPS lub z prywatnego adresu IP). Wcześniej było to zaplanowane w Chrome 92, dlatego komunikaty o wycofaniu mogą nadal zawierać wzmianki o wcześniejszym kamieniu milowym.
Wycofywanie obejmuje okres próbny, dzięki któremu deweloperzy stron internetowych, którzy korzystają z tej wycofanej funkcji, mogą z niej korzystać do Chrome 116, rejestrując tokeny. Instrukcje, jak zarejestrować się i włączyć okres próbny w witrynie, znajdziesz poniżej.
Za pomocą pary zasad Chrome można na stałe wyłączyć wycofanie całkowicie lub w konkretnych źródłach. Dzięki temu zarządzane instalacje Chrome, np. te w ustawieniach firmowych, mogą uniknąć awarii.
Chrome 117
Okres próbny wycofywania się kończy. W przypadku wszystkich witryn należy wyłączyć tę funkcję lub skonfigurować zasady użytkowników w taki sposób, aby ta funkcja była nadal włączona.
Zalecane działania dewelopera
W przypadku witryn, których dotyczy problem, w pierwszej kolejności trzeba zwykle kupić czas do momentu wprowadzenia odpowiedniej poprawki, rejestrując się w okresie próbnym wycofywania lub stosując zasady. Następnie zalecane działania różnią się w zależności od sytuacji w każdej witrynie, której dotyczy problem.
Zarejestruj się, aby wziąć udział w okresie próbnym wycofania
- Kliknij Zarejestruj w sekcji testowania origin niezabezpieczonego kontekstu dostępu do sieci prywatnej, aby uzyskać token próbny dla uczestniczącego źródła.
- Dodaj
Origin-Trial: $tokenpowiązany z punktem początkowym do nagłówka odpowiedzi. Ten nagłówek odpowiedzi należy ustawić w odpowiedziach dotyczących zasobu głównego i nawigacji tylko wtedy, gdy dokument zawiera wycofaną funkcję. Dołączanie tego nagłówka do odpowiedzi zasobów podrzędnych nie ma sensu (ale jest bezpieczne).
Zanim dokument będzie mógł wysyłać żądania, trzeba włączyć lub wyłączyć wersję próbną, więc nie można jej włączyć za pomocą tagu <meta>. Takie tagi są analizowane z treści odpowiedzi dopiero po wysłaniu żądań zasobów podrzędnych. Stanowi to wyzwanie dla witryn, które nie mają kontroli nad nagłówkami odpowiedzi, np. witryn statycznych github.io wyświetlanych przez firmy zewnętrzne.
Więcej informacji znajdziesz w przewodniku po testach origin dla programistów stron internetowych.
Włącz zasady
Jeśli masz kontrolę administracyjną nad użytkownikami, możesz ponownie włączyć wycofaną funkcję przy użyciu jednej z tych zasad:
Więcej informacji o zarządzaniu zasadami obowiązującymi użytkowników znajdziesz w tym artykule w Centrum pomocy.
Uzyskiwanie dostępu do hosta lokalnego
Jeśli Twoja witryna musi wysyłać żądania do lokalnego hosta, musisz tylko uaktualnić ją do HTTPS.
Żądania kierowane na zasady http://localhost (lub http://127.*.*.*, http://[::1]) nie są blokowane przez treści mieszane, nawet jeśli są wysyłane z bezpiecznych kontekstów.
Pamiętaj, że mechanizm WebKit i oparte na nim przeglądarki (a zwłaszcza Safari) odbiegają od specyfikacji treści mieszanych W3C i nie zezwalają na przesyłanie takich żądań jako treści mieszanych. Nie stosują też dostępu do sieci prywatnej, dlatego witryny mogą zechcieć przekierowywać klientów korzystających z takich przeglądarek do wersji HTTP stron internetowych w formie zwykłego tekstu, która nadal będzie dozwolona w przypadku tych przeglądarek na wysyłanie żądań do lokalnego hosta.
Dostęp do prywatnych adresów IP
Jeśli Twoja witryna musi wysyłać żądania do serwera docelowego z prywatnego adresu IP, zaktualizowanie witryny inicjującej do protokołu HTTPS nie zadziała. Treści mieszane zapobiegają wysyłaniu żądań przez bezpieczne konteksty za pomocą zwykłego tekstu HTTP, dlatego nowo zabezpieczona witryna nie będzie w stanie wysyłać żądań. Problem ten można rozwiązać na kilka sposobów:
- Uaktualnij obie strony do HTTPS.
- Używaj WebTransport do bezpiecznego łączenia się z serwerem docelowym.
- Odwróć relację umieszczania.
Uaktualnij obie strony do HTTPS
To rozwiązanie wymaga kontroli nad rozpoznawaniem nazw DNS użytkowników. Może tak być np. w intranecie lub na tym, czy użytkownicy uzyskują adresy swoich serwerów nazw z kontrolowanego przez Ciebie serwera DHCP. Musisz też mieć nazwę domeny publicznej.
Głównym problemem związanym z obsługą witryn prywatnych przez protokół HTTPS jest to, że urzędy certyfikacji infrastruktury klucza publicznego (PKI CA) dostarczają certyfikaty TLS tylko witrynom z nazwami domeny publicznej. Aby obejść ten problem:
- Zarejestruj nazwę domeny publicznej (na przykład
intranet.example) i opublikuj rekordy DNS wskazujące tę nazwę na wybranym przez siebie serwerze publicznym. - Uzyskaj certyfikat TLS dla domeny
intranet.example. - W sieci prywatnej skonfiguruj DNS tak, aby adres
intranet.examplebył zgodny z prywatnym adresem IP serwera docelowego. - Skonfiguruj swój prywatny serwer do korzystania z certyfikatu TLS do obsługi strony
intranet.example. Dzięki temu użytkownicy będą mieli dostęp do prywatnego serwera w domeniehttps://intranet.example.
Możesz uaktualnić witrynę, która wysyła żądania do HTTPS, i kontynuować ich wysyłanie tak jak wcześniej.
To rozwiązanie jest przyjazne dla przyszłości i zmniejsza zaufanie, którym obdarzasz swoją sieć, dzięki czemu zwiększa się wykorzystanie pełnego szyfrowania w sieci prywatnej.
WebTransport
To rozwiązanie nie wymaga kontroli nad rozpoznawaniem nazw DNS użytkowników. Wymaga on, aby na serwerze docelowym uruchomiono minimalny serwer WebTransport (HTTP/3 z pewnymi modyfikacjami).
Aby pominąć brak ważnego certyfikatu TLS podpisanego przez zaufany urząd certyfikacji, możesz użyć WebTransport i mechanizmu przypinania certyfikatów. Pozwala to nawiązywać bezpieczne połączenia z prywatnymi urządzeniami, które mogą na przykład mieć certyfikat podpisany samodzielnie. Połączenia WebTransport pozwalają na dwukierunkowe przesyłanie danych, ale nie pozwalają na pobieranie żądań. Możesz połączyć to podejście z mechanizmem Service Worker, aby w przejrzysty sposób pośredniczyć w żądaniach HTTP przez połączenie z perspektywy swojej aplikacji internetowej. Po stronie serwera odpowiednia warstwa translacji może przekonwertować wiadomości WebTransport na żądania HTTP.
Zdajemy sobie sprawę, że wymaga to sporo pracy, ale powinno być znacznie łatwiejsze niż tworzenie nowych rozwiązań na WebRTC. Mamy też nadzieję, że pewna część niezbędnych inwestycji zostanie wdrożona jako biblioteki wielokrotnego użytku. Sądzimy też, że warto wziąć pod uwagę fakt, że niezabezpieczone konteksty mogą najczęściej tracić dostęp do coraz większej liczby funkcji platformy internetowej, ponieważ platforma z czasem coraz skuteczniej zachęca do korzystania z protokołu HTTPS. Niezależnie od dostępu do sieci prywatnej inwestycja ta i tak byłaby korzystna.
Spodziewamy się, że protokół WebTransport w ramach protokołu HTTP/3 będzie dostępny w Chrome 96 (rozpoczęliśmy testowanie origin) z zastosowaniem środków mających na celu ochronę przed udostępnianiem kluczy i innymi niestandardowymi praktykami dotyczącymi bezpieczeństwa, takimi jak:
- Krótki maksymalny czas wygaśnięcia przypiętych certyfikatów.
- Specjalny w przeglądarce mechanizm unieważniania określonych kluczy, które zostały naruszone.
Bezpieczne ograniczenie kontekstu zostanie udostępnione dopiero po upływie co najmniej 2 etapów po pełnym wdrożeniu WebTransport. W razie potrzeby okres próbny wycofania zostanie przedłużony.
Odwrotne umieszczanie
To rozwiązanie nie wymaga żadnej kontroli administracyjnej nad siecią i można go używać, gdy serwer docelowy nie jest wystarczająco wydajny, aby obsługiwać protokół HTTPS.
Zamiast pobierać prywatne zasoby podrzędne z publicznej aplikacji internetowej, można udostępnić jej szkielet aplikacji z serwera prywatnego, który następnie pobiera wszystkie swoje zasoby podrzędne (takie jak skrypty czy obrazy) z serwera publicznego (np. sieci CDN). Powstała w ten sposób aplikacja internetowa może następnie wysyłać żądania do serwera prywatnego, ponieważ jest on uznawany za serwer z tej samej domeny. Może nawet wysyłać żądania do innych serwerów z prywatnymi adresami IP (ale nie do lokalnego hosta), choć w dłuższej perspektywie może się to zmienić.
Hostując tylko szkielet na serwerze prywatnym, możesz zaktualizować aplikację internetową, przesyłając nowe zasoby na serwer publiczny, tak jak w przypadku publicznej aplikacji internetowej. Z drugiej strony aplikacja internetowa nie jest zabezpieczonym kontekstem, więc nie ma dostępu do niektórych zaawansowanych funkcji sieci.
Plany na przyszłość
Ograniczenie żądań z sieci prywatnej do bezpiecznych kontekstów to dopiero pierwszy krok do uruchomienia dostępu do sieci prywatnej. Chrome pracuje nad wdrożeniem pozostałych specyfikacji w najbliższych miesiącach. Będziemy na bieżąco informować o zmianach.
Ograniczanie dostępu hosta lokalnego ze stron prywatnych
Zmiany w Chrome 94 wpływają tylko na witryny publiczne mające dostęp do prywatnych adresów IP lub hosta lokalnego. Specyfikacja dostępu do sieci prywatnej również klasyfikuje jako problematyczne żądania wysyłane z witryn prywatnych do hosta lokalnego. Chrome je z czasem wycofa. Wiąże się to jednak z nieco innymi wyzwaniami, ponieważ wiele witryn prywatnych nie ma nazw domen, co komplikuje korzystanie z próbnych tokenów wycofywania.
Żądania procesów wstępnych CORS
Drugą częścią dostępu do sieci prywatnej jest blokowanie żądań sieci prywatnych inicjowanych z bezpiecznych kontekstów za pomocą żądań wstępnych CORS. Oznacza to, że nawet jeśli żądanie zostało zainicjowane z bezpiecznego kontekstu, serwer docelowy jest proszony o jednoznaczne przyznanie inicjatora. Żądanie jest wysyłane tylko wtedy, gdy uwierzytelnienie się powiedzie.
Krótko mówiąc, żądanie procesu wstępnego CORS to żądanie HTTP OPTIONS z nagłówkami Access-Control-Request-* wskazującymi charakter kolejnego żądania. Serwer może wtedy zdecydować, czy udzielić szczegółowego dostępu, odpowiadając 200 OK przy użyciu nagłówków Access-Control-Allow-*.
Więcej informacji na ten temat znajdziesz w specyfikacji.
Ograniczenie pobierania przez nawigację
Chrome wycofuje i w końcu blokuje żądania zasobów podrzędnych wysyłane do sieci prywatnych. Nie będzie to miało wpływu na nawigację do sieci prywatnych, których można używać również w atakach CSRF.
Specyfikacja dostępu do sieci prywatnej nie rozróżnia 2 rodzajów pobierania, które ostatecznie będą podlegać tym samym ograniczeniom.
Zdjęcie na okładkę: Markus Spiske w programie Unsplash