Open Redirect¶

Open Redirect to podatność polegająca na tym, że aplikacja przekierowuje użytkownika na adres URL wskazany w parametrze żądania bez odpowiedniej walidacji. Atakujący może skonstruować link prowadzący przez zaufaną domenę aplikacji, który ostatecznie kieruje ofiarę na stronę kontrolowaną przez niego.

Podatność sama w sobie nie prowadzi zazwyczaj do bezpośredniego naruszenia poufności lub integralności aplikacji, jednak jest często wykorzystywana jako warstwa uwiarygadniająca w atakach socjotechnicznych (phishing) oraz jako jeden z elementów łańcucha ataku prowadzącego do poważniejszych podatności.

Skutki udanego ataku¶

Open Redirect może być wykorzystany następująco:

phishing - link wygląda na pochodzący z zaufanej domeny aplikacji, lecz ostatecznie prowadzi do strony atakującego,
kradzież tokenów autoryzacyjnych poprzez przekierowanie do kontrolowanego punktu,
omijanie filtrów antyphishingowych i bezpieczeństwa poczty (URL „zaufany" z punktu widzenia skanerów),
wykorzystanie podatności jako elementu bardziej złożonych ataków, np. phishingu lub nieprawidłowo zabezpieczonych przepływów OAuth/OIDC,
naruszenie zaufania do marki i reputacji usługi.

Mechanizm działania¶

Aplikacja przyjmuje parametr określający adres docelowy i przekierowuje do niego:

GET /login?next=/dashboard HTTP/1.1

lub:

GET /redirect?url=https://example.com/start HTTP/1.1

Jeśli aplikacja nie waliduje wartości next/url, atakujący może wskazać zewnętrzną domenę:

https://trusted.example/redirect?url=https://attacker.example/

Serwer odpowiada:

HTTP/1.1 302 Found
Location: https://attacker.example/

i przeglądarka ofiary trafia na stronę atakującego.

Uwaga

Weryfikacja zaczynająca się od „czy URL zawiera moją domenę" jest błędna. Walidacja powinna wykorzystywać jeden, zgodny z późniejszym sposobem użycia parser URL i sprawdzać wszystkie istotne elementy adresu, w szczególności schemat, host oraz port. Nie należy podejmować decyzji na podstawie wyszukiwania nazwy domeny w surowym ciągu znaków.

Charakterystyka¶

Podatność Open Redirect może wystąpić w funkcjach, które ustalają adres przekierowania na podstawie danych przekazanych przez użytkownika. Typowe przykłady obejmują:

przekierowania po logowaniu/wylogowaniu (?next=, ?returnTo=, ?redirect=),
obsługę przepływów OAuth/OIDC z nieprawidłową walidacją parametru redirect_uri,
mechanizmy skracania linków oraz udostępniania odnośników, jeżeli powodują przekierowanie do adresu wskazanego przez użytkownika,
endpointy przekierowujące na podstawie parametrów takich jak url lub target,
zapisywanie adresu poprzednio odwiedzonej strony i przekierowywanie do niego bez odpowiedniej walidacji.

Rekomendacje¶

Aby ograniczyć ryzyko występowania podatności należy:

Nie przekierowywać na zewnętrzne adresy URL na podstawie parametru użytkownika. Jeżeli przekierowanie dotyczy tylko zasobów aplikacji, należy używać ścieżek względnych:
```
next=/dashboard
```
i po stronie serwera składać pełny URL z własnej, stałej domeny konfiguracyjnej.

Stosować allowlistę dozwolonych celów przekierowania - porównywanie po normalizacji i z dokładnym dopasowaniem hosta (przykład uproszczony):

from urllib.parse import urlparse
allowed_hosts = {"trusted.example", "app.trusted.example"}

def is_safe(url):
    host = urlparse(url).hostname
    return host in allowed_hosts

Walidować redirect_uri w OAuth/OIDC dokładnie (dokładne dopasowanie zarejestrowanych URI), nie prefix-match.
Odrzucać schematy inne niż http/https (w szczególności javascript:, data:, file:, vbscript:).
Unikać przekierowań pośrednich przez użytkownika-kontrolowane URL; preferować stałe trasy w aplikacji.
Należy jawnie odrzucać adresy w formacie scheme-relative (tzw. protocol-relative URL), czyli zaczynające się od // bez podania schematu, np. //evil.example - przeglądarka interpretuje je względem protokołu bieżącej strony, więc mimo braku http:/https: nadal prowadzą do przekierowania na zewnętrzną domenę. Tak samo należy odrzucać warianty z backslashem (np. /\evil.example, \evil.example) oraz adresy zawierające znaki sterujące, stosując jeden, jednoznacznie zdefiniowany proces parsowania i normalizacji. Więcej o tym mechanizmie i sposobach obejścia walidacji można przeczytać w dokumencie: OWASP Testing Guide - Testing for Client-side URL Redirect.
Logować i monitorować przekierowania, zwłaszcza te wskazujące na nietypowe, zewnętrzne domeny.