Potrzebna opinia: CORS dla sieci prywatnych (RFC1918)

Ograniczanie ryzyka związanego z nieumyślnym udostępnieniem 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 ramach sieci prywatnej od dawna stanowią zagrożenie. Hakerzy mogą na przykład zmienić konfigurację routera bezprzewodowego, aby umożliwić przeprowadzanie ataków Man-in-the-Middle. CORS-RFC1918 to propozycja dotycząca blokowania takich żądań domyślnie w przeglądarce i wymagania od urządzeń wewnętrznych wyrażenia zgody na żądania z publicznego internetu.

Aby zrozumieć, jak ta zmiana wpływa na ekosystem internetu, zespół Chrome prosi o opinie programistów, którzy tworzą serwery dla sieci prywatnych.

Co jest nie tak z obecną sytuacją?

Wiele serwerów WWW działa w ramach sieci prywatnej, a dopiero na nich działają routery bezprzewodowe, drukarki, witryny intranetowe, usługi korporacyjne i urządzenia Internetu Rzeczy (IoT). Mogą one wydawać się bezpieczniejsze niż serwery publiczne, ale atakujący mogą wykorzystywać te serwery, używając strony internetowej jako serwera proxy. Na przykład złośliwe witryny mogą zawierać adres URL, który po wyświetleniu przez ofiarę (w przeglądarce z włączonym JavaScriptem) próbuje zmienić ustawienia serwera DNS na domowym routerze ofiary. Ten typ ataku nazywa się „Drive-By Pharming” i wystąpił w 2014 r. Wykorzystano ponad 300 tys. podatnych routerów bezprzewodowych,zmieniając ich ustawienia DNS i umożliwiając atakującym przekierowywanie użytkowników do złośliwych serwerów.

CORS-RFC1918

Aby zminimalizować zagrożenie podobnymi atakami, społeczność internetowa wprowadza mechanizm CORS-RFC1918 – współdzielenie zasobów pomiędzy serwerami z różnych domen (CORS), który jest dostosowany do sieci prywatnych zdefiniowanych w RFC1918.

Przeglądarki, które implementują CORS, sprawdzają u docelowych zasobów, czy można je wczytywać z innego źródła. W zależności od złożoności można to zrobić za pomocą dodatkowych nagłówków opisujących dostęp lub za pomocą mechanizmu o nazwie żądania wstępnej weryfikacji. Aby dowiedzieć się więcej, przeczytaj artykuł Mechanizm CORS.

W przypadku CORS-RFC1918 przeglądarka domyślnie blokuje wczytywanie zasobów przez sieć prywatną, z wyjątkiem tych, które są wyraźnie dozwolone przez serwer za pomocą CORS i protokołu HTTPS. Witryna wysyłająca żądania do tych zasobów musi wysyłać nagłówki CORS, a serwer musi wyraźnie stwierdzić, że akceptuje żądanie między domenami, odpowiadając odpowiednimi nagłówkami CORS. (dokładne nagłówki CORS są nadal w fazie opracowywania).

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ę serwera dla CORS-RFC1918 i odpowiedz oczekiwanymi nagłówkami HTTP.

Jakich rodzajów żądań dotyczy zmiana?

Dotyczy to m.in. tych żądań:

  • żą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 mapowane na prywatną przestrzeń adresów zdefiniowaną w sekcji 3 normy RFC1918 w IPv4, adres IPv6 mapowany na adres IPv4, gdzie mapowany adres IPv4 jest prywatny, lub adres IPv6 poza podsieciami ::1/128, 2000::/3 i ff00::/8.

Sieć lokalna Adres docelowy, który jest mapowany na przestrzeń „loopback” (127.0.0.0/8) zdefiniowaną w sekcji 3.2.1.3 dokumentu RFC1122 dotyczącego IPv4, przestrzeń „link-local” (169.254.0.0/16) zdefiniowana w sekcji RFC3927 dotycząca IPv4, prefiks „Unique Local Address” (fc00::/7) zdefiniowany w sekcji 3 dokumentu RFC4193 dotyczącego IPv6 lub prefiks „link-local” (fe80::/10) zdefiniowany w sekcji 2.5.6 dokumentu RFC4291 dotyczącego IPv6.

Sieć publiczna Wszystkie inne.

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

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

Chrome wprowadza mechanizm CORS-RFC1918 w 2 krokach:

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

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

Od Chrome 88 błędy CORS-RFC1918 będą raportowane w konsoli jako błędy związane z zasadami CORS.

Błędy CORS-RFC1918 będą zgłaszane w konsoli jako błędy związane z zasadami CORS.
Błędy związane z specyfikacją CORS-RFC1918 będą raportowane w Konsoli jako błędy związane z zasadami CORS.

W panelu Sieć w Narzędziach dla deweloperów w Chrome możesz zaznaczyć pole wyboru Zablokowane żądania, aby wyświetlić tylko zablokowane żądania:

Błędy CORS-RFC1918 będą również zgłaszane jako błędy CORS w panelu Sieć.
Błędy CORS-RFC1918 będą również 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ć samodzielnie, korzystając z witryny testowej.

Krok 2. Wysyłanie żądań wstępnej kontroli z użyciem specjalnego nagłówka

W przyszłości, gdy publiczna witryna będzie próbować pobrać zasoby z sieci prywatnej lub lokalnej, Chrome będzie wysyłać prośbę wstępną przed wysłaniem rzeczywistej prośby.

Żądanie będzie zawierać nagłówek Access-Control-Request-Private-Network: trueoraz inne nagłówki żądań CORS. Te nagłówki wskazują między innymi źródło wysyłające żądanie, co umożliwia szczegółową 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.

Prośba o 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. Możesz pomóc na 2 sposoby:

  • Otwórz stronę 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 obsługuje stronę internetową administratora w ramach tej samej sieci prywatnej, ale przez HTTP. Jeśli w przypadku witryn, które zawierają witrynę administracyjną, wymagany jest protokół HTTPS, będą to treści mieszane. Czy w przypadku sieci zamkniętej należy włączyć HTTPS w witrynie administracyjnej?

To właśnie tego typu opinie potrzebujemy. Zgłoś problem na stronie crbug.com, podając konkretny przypadek użycia. Zespół Chrome chętnie Cię wysłucha.

Baner powitalny autorstwa Stephen Philips na Unsplash.