Potrzebna opinia: CORS dla sieci prywatnych (RFC1918)

Ograniczanie ryzyka związanego z niezamierzonym udostępnianiem urządzeń i serwerów w sieci wewnętrznej klienta w internecie.

Eiji Kitamura

Złośliwe witryny wysyłające żądania do urządzeń i serwerów hostowanych w sieci prywatnej od dawna stanowią zagrożenie. Hakerzy mogą na przykład zmienić konfigurację routera bezprzewodowego, aby umożliwić ataki typu Man-in-the-Middle. CORS-RFC1918 to propozycja domyślnego blokowania takich żądań w przeglądarce i wymagania, aby urządzenia wewnętrzne wyrażały zgodę na żądania z publicznego internetu.

Aby zrozumieć, jak ta zmiana wpływa na ekosystem internetu, zespół Chrome szuka opinii deweloperów, którzy tworzą serwery dla sieci prywatnych.

Co jest nie tak z obecnym stanem rzeczy?

Wiele serwerów internetowych działa w sieci prywatnej – routery bezprzewodowe, drukarki, witryny intranetowe, usługi dla firm i urządzenia internetu rzeczy (IoT) to tylko niektóre z nich. Mogą one wydawać się bezpieczniejsze niż te, które są dostępne publicznie, ale mogą być wykorzystywane przez atakujących, którzy używają strony internetowej jako serwera proxy. Na przykład złośliwe witryny mogą zawierać adres URL, który po prostu wyświetlony przez ofiarę (w przeglądarce z włączoną obsługą JavaScript) próbuje zmienić ustawienia serwera DNS na routerze szerokopasmowym ofiary. Ten rodzaj ataku nazywa się „Drive-By Pharming” i miał miejsce w 2014 r. Wykorzystano ponad 300 tys. podatnych na ataki routerów bezprzewodowych,zmieniając ich ustawienia DNS i umożliwiając atakującym przekierowywanie użytkowników na złośliwe serwery.

CORS-RFC1918

Aby zmniejszyć zagrożenie podobnymi atakami, społeczność internetowa wprowadza CORS-RFC1918, czyli specjalistyczny mechanizm współdzielenia zasobów między serwerami z różnych domen (CORS) dla sieci prywatnych zdefiniowanych w RFC1918.

Przeglądarki, które implementują sprawdzanie CORS, sprawdzają w zasobach docelowych, czy można je załadować z innego źródła. Można to osiągnąć za pomocą dodatkowych nagłówków w treści opisujących dostęp lub za pomocą mechanizmu zwanego żądaniami wstępnymi, w zależności od złożoności. Więcej informacji znajdziesz w artykule Współdzielenie zasobów pomiędzy serwerami z różnych domen.

W przypadku CORS-RFC1918 przeglądarka domyślnie blokuje wczytywanie zasobów w sieci prywatnej z wyjątkiem tych, które są wyraźnie dozwolone przez serwer za pomocą mechanizmu CORS i protokołu HTTPS. Witryna wysyłająca żądania do tych zasobów będzie musiała wysyłać nagłówki CORS, a serwer będzie musiał wyraźnie stwierdzić, że akceptuje żądanie dotyczące zasobów z innej domeny, odpowiadając odpowiednimi nagłówkami CORS. (Dokładne nagłówki CORS są nadal w fazie rozwoju).

Deweloperzy takich urządzeń lub serwerów będą musieli wykonać 2 czynności:

Upewnij się, że witryna wysyłająca żądania do sieci prywatnej jest udostępniana przez HTTPS.
Skonfiguruj obsługę CORS-RFC1918 na serwerze i odpowiadaj za pomocą oczekiwanych nagłówków HTTP.

Jakich rodzajów żądań dotyczy problem?

Żądania, których to dotyczy, obejmują:

Żądania z sieci publicznej do sieci prywatnej
Żądania z sieci prywatnej do sieci lokalnej
Żądania z sieci publicznej do sieci lokalnej

Sieć prywatna Miejsce docelowe, które jest rozpoznawane jako prywatna przestrzeń adresów zdefiniowana w sekcji 3 RFC1918 w IPv4, adres IPv6 zmapowany na IPv4, w którym zmapowany adres IPv4 jest prywatny, lub adres IPv6 poza podsieciami ::1/128, 2000::/3 i ff00::/8.

Sieć lokalna Miejsce docelowe, które jest rozpoznawane jako przestrzeń „loopback” (127.0.0.0/8) zdefiniowana w punkcie 3.2.1.3 dokumentu RFC1122 protokołu IPv4, przestrzeń „link-local” (169.254.0.0/16) zdefiniowana w dokumencie RFC3927 protokołu IPv4, prefiks „Unique Local Address” (fc00::/7) zdefiniowany w punkcie 3 dokumentu RFC4193 protokołu IPv6 lub prefiks „link-local” (fe80::/10) zdefiniowany w punkcie 2.5.6 dokumentu RFC4291 protokołu IPv6.

Sieć publiczna Wszystkie inne.

Relacja między sieciami publicznymi, prywatnymi i lokalnymi w CORS-RFC1918 — Relacja między sieciami publicznymi, prywatnymi i lokalnymi w mechanizmie CORS-RFC1918

Plany Chrome dotyczące włączenia CORS-RFC1918

Chrome wprowadza CORS-RFC1918 w 2 etapach:

Krok 1. Żądania do zasobów sieci prywatnej będą dozwolone tylko ze stron internetowych HTTPS

W Chrome 87 dodaliśmy flagę, która wymaga, aby publiczne witryny wysyłające żądania do zasobów sieci prywatnych korzystały z protokołu HTTPS. Aby ją włączyć, otwórz about://flags#block-insecure-private-network-requests. Gdy ten flag jest włączony, wszystkie żądania zasobu sieci prywatnej z witryny HTTP będą blokowane.

Od Chrome 88 błędy CORS-RFC1918 będą zgłaszane w konsoli jako błędy zasad CORS.

W panelu Sieć w Narzędziach deweloperskich w Chrome możesz zaznaczyć pole wyboru Zablokowane żądania, aby skupić się na zablokowanych żądaniach:

Błędy CORS-RFC1918 będą też zgłaszane jako błędy CORS w panelu Sieć. — Błędy CORS-RFC1918 będą też zgłaszane jako błędy CORS w panelu **Sieć**.

W Chrome 87 błędy CORS-RFC1918 są zgłaszane tylko w konsoli Narzędzi deweloperskich jako ERR_INSECURE_PRIVATE_NETWORK_REQUEST.

Możesz to sprawdzić na tej testowej stronie.

Krok 2. Wysyłanie żądań wstępnych ze specjalnym nagłówkiem

W przyszłości, gdy publiczna witryna będzie próbować pobrać zasoby z sieci prywatnej lub lokalnej, Chrome wyśle żądanie wstępne przed wysłaniem właściwego żądania.

Żądanie będzie zawierać nagłówek Access-Control-Request-Private-Network: true oprócz innych nagłówków żądań CORS. Te nagłówki identyfikują m.in. źródło żądania, co umożliwia precyzyjną kontrolę dostępu. Serwer może odpowiedzieć nagłówkiem Access-Control-Allow-Private-Network: true, aby wyraźnie wskazać, że przyznaje dostęp do zasobu.

Czekamy na Twoją opinię

Jeśli hostujesz witrynę w sieci prywatnej, która oczekuje żądań z sieci publicznych, zespół Chrome jest zainteresowany Twoimi opiniami i przypadkami użycia. Możesz zrobić 2 rzeczy:

Otwórz about://flags#block-insecure-private-network-requests, włącz flagę i sprawdź, czy Twoja witryna wysyła żądania do zasobu sieci prywatnej zgodnie z oczekiwaniami.
Jeśli napotkasz problemy lub chcesz podzielić się opinią, zgłoś problem na stronie crbug.com i ustaw komponent na Blink>SecurityFeature>CORS>RFC1918.

Przykładowa opinia

Nasz router bezprzewodowy udostępnia witrynę administracyjną dla tej samej sieci prywatnej, ale za pomocą protokołu HTTP. Jeśli protokół HTTPS jest wymagany w przypadku witryn, które osadzają witrynę administracyjną, będzie to treść mieszana. Czy w sieci zamkniętej należy włączyć protokół HTTPS w witrynie administracyjnej?

To jest dokładnie ten rodzaj opinii, na którym zależy zespołowi Chrome. Zgłoś problem z konkretnym przypadkiem użycia na stronie crbug.com. Chętnie poznamy Twoją opinię.