@angular/platform-server: Open Redirect poprzez adresy URL względne względem protokołu w Server-Side Rendering (SSR)

Zidentyfikowano podatność typu open redirect w @angular/platform-server, gdy włączone jest Server-Side Rendering (SSR).

Gdy Angular SSR przetwarza przychodzące żądanie, translacja URL i nawigacja platformy są zarządzane przez ServerPlatformLocation przy użyciu resolveUrl (lub parseUrl w v20). Chociaż resolveUrl odrzucał adresy URL względne względem protokołu, których surowy ciąg znaków zaczynał się bezpośrednio od //, weryfikacja ta była wykonywana przed normalizacją WHATWG URL.

Gdy adres URL żądania zawiera segment z kropkami cofającymi ścieżkę, po którym następuje wiele ukośników (taki jak /.//evil.test lub zserializowany z definicji tras routera, np. /.;/(//evil.test)), dane wejściowe omijały wstępne sprawdzenie urlStr.startsWith('//'). Dalsze przetwarzanie WHATWG URL rozwiązywało segmenty kropek i skutkowało wartością pathname rozpoczynającą się od // (//evil.test).

W konsekwencji ServerPlatformLocation zapisywał pathname = '//evil.test'. Gdy @angular/ssr wykrywał niezgodność między wyrenderowanym adresem URL a ostatecznym stanem lokalizacji routera, emitował nienormalizowaną ścieżkę w nagłówku odpowiedzi HTTP Location, generując przekierowanie HTTP 302 z Location: //evil.test, które przeglądarki interpretują jako nawigację względną względem protokołu poza domenę źródłową.

Wpływ

Skuteczne wykorzystanie podatności pozwala nieuwierzytelnionemu zdalnemu atakującemu na spreparowanie adresów URL, które zmuszają Angular SSR do przekierowania użytkowników na dowolną zewnętrzną domenę.

• Obejście zabezpieczeń na poziomie aplikacji: Standardowe procedury walidacji aplikacji (np. sprawdzanie !returnUrl.startsWith('//') przed wywołaniem router.navigateByUrl) akceptują /.//evil.test lub /.;/(//evil.test) jako bezpieczną ścieżkę względną, co pozwala atakującym na obejście reguł allowlisty przekierowań.
• Brak wpływu na aplikacje SPA po stronie klienta: Aplikacje Angular działające wyłącznie po stronie klienta (Single Page Applications bez SSR) nie są podatne, ponieważ ServerPlatformLocation jest wykorzystywane tylko w środowiskach uruchomieniowych po stronie serwera.

Warunki wstępne ataku i podatne konfiguracje

Aplikacja jest podatna, jeśli spełnione są następujące warunki:

• Włączone SSR: Aplikacja działa w środowisku Server-Side Rendering z wykorzystaniem @angular/platform-server i @angular/ssr.
• Wzorce tras z parametrami: Router zawiera trasy z parametrami, symbolami wieloznacznymi lub segmentami podrzędnymi (np. /:tenant pasujące do . i serializujące dodatkowe grupy outletów (//evil.test) do /.//evil.test) lub przekazuje cele nawigacji dostarczone przez użytkownika (np. returnUrl).
• Przepuszczanie przez Reverse Proxy: Zewnętrzne serwery reverse proxy (Nginx, Cloudflare, ALB) przekazują średniki (;) lub segmenty z kropkami bez ich usuwania lub normalizacji.

Przykład żądania eksploitującego

Atakujący wysyła żądanie skierowane na trasę z parametrami i segmentami podrzędnymi:

GET /.;/(//evil.test) HTTP/1.1
Host: example.com

Odpowiedź:

HTTP/1.1 302 Found
Location: //evil.test

Przeglądarka klienta interpretuje //evil.test w sposób względny względem protokołu i przekierowuje użytkownika z example.com do evil.test.

Poprawki

Problem rozwiązano poprzez aktualizację resolveUrl (oraz parseUrl w v20) w @angular/platform-server, aby upewnić się, że znormalizowana ścieżka URL nie zaczyna się od //, gdy allowProtocolRelative ma wartość false.

• 22.2.1
• 21.2.25
• 20.3.33

Obejścia i mitygacje

Jeśli nie można natychmiast dokonać aktualizacji do załatanej wersji, należy wdrożyć jedno z poniższych rozwiązań na brzegu sieci (reverse proxy lub WAF):

1. Odrzucanie ścieżek z segmentami kropek poprzedzającymi ukośniki: Skonfiguruj serwer reverse proxy (np. Nginx, Cloudflare, AWS WAF), aby blokował żądania zawierające /.//, /..// lub /.;/:
   nginx

   # Nginx example: reject suspicious path normalization sequences
   if ($request_uri ~* "(\n/\.\/|\/\.\;)") {
       return 400;
   }

2. Sanityzacja nagłówków przekierowań: Upewnij się, że serwery proxy lub bramy API przepisują lub blokują nagłówki odpowiedzi Location względne względem protokołu (//) pochodzące z upstreamu SSR.