Potrzebna opinia: CORS dla sieci prywatnych (RFC1918)

Ograniczanie ryzyka związanego z niezamierzonym ujawnieniem urządzeń i serwerów w wewnętrznej sieci klienta dla całej sieci.

Eiji Kitamura

Uwaga: aby zwiększyć przejrzystość, nazwa CORS-RFC1918 została zmieniona na Private Network Access (Dostęp do sieci prywatnej). Informacje na ten temat znajdziesz na developer.chrome.comblog.

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

Aby zrozumieć, jak ta zmiana wpływa na ekosystem internetowy, zespół Chrome czeka na opinie deweloperów, którzy budują serwery sieci prywatnych.

Co jest nie tak ze statusem quo?

Wiele serwerów WWW działa w sieci prywatnej. Routery bezprzewodowe, drukarki, strony intranetowe, usługi dla przedsiębiorstw i urządzenia korzystające z internetu rzeczy (IoT) stanowią tylko ich część. Mogą się wydawać, że znajdują się w bezpieczniejszym środowisku niż te dostępne publicznie, ale te serwery mogą zostać wykorzystane przez hakerów, którzy wykorzystują stronę internetową jako serwer proxy. Na przykład złośliwe witryny mogą umieścić adres URL, który po wyświetleniu go przez ofiarę (w przeglądarce z włączoną obsługą JavaScriptu) próbuje zmienić ustawienia serwera DNS na jego domowym routerze szerokopasmowym. Ten rodzaj ataku nazywa się „Drive-By Pharming” i przeprowadzono go w 2014 roku. Ponad 300 tys. luk w zabezpieczeniach routerów bezprzewodowych zostało wykorzystane przez zmianę ich ustawień DNS,co umożliwiło hakerom przekierowywanie użytkowników na złośliwe serwery.

CORS-RFC1918

Aby ograniczyć zagrożenie podobnymi atakami, społeczność internetowa wprowadza standard CORS-RFC1918 – CORS – specjalny w przypadku sieci prywatnych zdefiniowanych w dokumencie RFC1918.

Przeglądarki implementujące CORS sprawdzają przy użyciu zasobów docelowych, czy można je ładować z innego źródła. W zależności od złożoności wykorzystuje się w tym celu dodatkowe nagłówki z opisem dostępu lub mechanizm nazywany żądaniami wstępnymi. Więcej informacji znajdziesz w artykule na temat współdzielenia zasobów między serwerami z różnych domen.

Dzięki CORS-RFC1918 przeglądarka domyślnie blokuje ładowanie zasobów przez sieć prywatną, z wyjątkiem tych, które są jednoznacznie dozwolone przez serwer za pomocą CORS i HTTPS. Witryna, która wysyła żądania do tych zasobów, będzie musiała wysyłać nagłówki CORS, a serwer będzie musiał wyraźnie stwierdzać, że akceptuje żądania z innych domen, odpowiadając za pomocą odpowiednich nagłówków CORS. (Dokładne nagłówki CORS są nadal w trakcie opracowywania).

Deweloperzy takich urządzeń lub serwerów zostaną poproszeni o wykonanie 2 rzeczy:

• Upewnij się, że witryna wysyłająca żądania do sieci prywatnej jest obsługiwana przez HTTPS.
• Skonfiguruj obsługę CORS-RFC1918 przez serwer i odpowiedz, używając oczekiwanych nagłówków HTTP.

Jakich żądań dotyczy problem?

Dotyczy to:

• Żą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 prowadzi do prywatnej przestrzeni adresowej zdefiniowanej w sekcji 3 dokumentu RFC1918 w adresie IPv4, adres IPv6 zmapowany na IPv4, gdzie zmapowany adres IPv4 jest prywatny, lub adres IPv6 spoza podsieci ::1/128, 2000::/3 i ff00::/8.

Sieć lokalna Miejsce docelowe, które znajduje się w przestrzeni „loopback” (127.0.0.0/8) zdefiniowanej w sekcji 3.2.1.3 RFC1122 dotyczącej IPv4, w przestrzeni „link-local” (169.254.0.0/16) zdefiniowanej w RFC3927 IPv4, przez prefiks „Unikalny adres lokalny” (fc00::/7) zdefiniowany w sekcji 3. RFC 1.1.3. w sekcji RFC/5..{/1fe80::/10RFC4291

Sieć publiczna Wszystkie inne.

Związek między sieciami publicznymi, prywatnymi i lokalnymi w dokumencie CORS-RFC1918.

Chrome zamierza włączyć protokół CORS-RFC1918

Chrome wprowadza CORS-RFC1918 w 2 krokach:

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

Chrome 87 dodaje flagę, która nakazuje witrynom publicznym wysyłanie żądań do zasobów sieci prywatnej przez HTTPS. Możesz go włączyć na stronie about://flags#block-insecure-private-network-requests. Gdy ta flaga jest włączona, wszystkie żądania wysyłane z witryny HTTP do zasobu sieci prywatnej są blokowane.

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

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ć.

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

Możesz go wypróbować na tej stronie testowej.

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

W przyszłości, gdy witryna publiczna będzie próbować pobrać zasoby z sieci prywatnej lub lokalnej, Chrome wyśle żądanie procesu wstępnego przed rzeczywistym żądaniem.

Żądanie będzie zawierać nagłówek Access-Control-Request-Private-Network: true, a także inne nagłówki żądania CORS. Nagłówki te między innymi identyfikują źródło, z którego pochodzi żądanie, co pozwala na szczegółową kontrolę dostępu. W odpowiedzi serwer może wysłać nagłówek Access-Control-Allow-Private-Network: true, który wyraźnie wskazuje, że przyznaje dostęp do zasobu.

Uwaga: nagłówki są nadal w fazie rozwoju i w przyszłości mogą się zmienić. W tej chwili nie musisz nic robić.

Potrzebujemy opinii

Jeśli hostujesz witrynę w sieci prywatnej, która oczekuje żądań z sieci publicznych, zespół Chrome zapozna się z Twoimi opiniami i przypadkami użycia. Możesz mu pomóc na 2 sposoby:

• Otwórz about://flags#block-insecure-private-network-requests, włącz flagę i sprawdź, czy Twoja witryna zgodnie z oczekiwaniami wysyła żądania do zasobu sieci prywatnej.
• Jeśli napotkasz jakieś 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 prowadzi do strony administratora tej samej sieci prywatnej, ale przez HTTP. Jeśli w przypadku witryn, w których znajduje się witryna administratora, wymagany jest protokół HTTPS, będzie to treść mieszana. Czy włączyć HTTPS w witrynie administratora w sieci zamkniętej?

Tego rodzaju opinii oczekuje Chrome. Problem związany z konkretnym przypadkiem użycia zgłoś na stronie crbug.com. Chrome chętnie pozna Twoją opinię.

Baner powitalny autorstwa Stephen Philips w filmie Unsplash.