open redirect

Open redirect to podatność, w której aplikacja internetowa przyjmuje od użytkownika adres zewnętrznej strony i używa go w przekierowaniu ^[1]. W katalogu MITRE odpowiada jej słabość CWE-601, znana też jako otwarte przekierowanie, przekierowanie między domenami albo przekierowanie niewalidowane ^[1]. Efektem jest link, który zaczyna się od zaufanej domeny, a kończy na stronie atakującego. Sekurak nazywa open redirect podatnością dość powszechną w aplikacjach webowych ^[6].

Jak działa

Wiele aplikacji przekazuje w adresie informację, dokąd odesłać użytkownika po zalogowaniu, wylogowaniu albo kliknięciu w baner. Jeżeli aplikacja przekierowuje pod ten adres bez sprawdzenia, atakujący może podstawić własny. OWASP opisuje ten mechanizm jako przyjmowanie niezaufanych danych, które mogą sprawić, że aplikacja przekieruje żądanie pod zawarty w nich adres ^[2].

Siła ataku bierze się z wyglądu linku. Ponieważ nazwa serwera w zmodyfikowanym linku jest taka sama jak w oryginalnej witrynie, próba phishingu wygląda bardziej wiarygodnie ^[2]. Ofiara widzi znaną domenę, na przykład example.com, a filtry oceniające linki po domenie mogą go przepuścić. Przebieg pokazuje schemat poniżej.

RYS. 1Phishing przez otwarte przekierowanie

Zagrożenia i skutki

MITRE wymienia dwie główne grupy skutków ^[1]. Pierwsza to przekierowanie na strony ze złośliwym oprogramowaniem, w tym ataki drive-by download, które pobierają plik bez zgody użytkownika ^[1]. Druga to phishing: strona naśladująca zaufany serwis wyłudza dane uwierzytelniające, które posłużą do przejęcia konta ^[1].

OWASP dodaje skutek mniej oczywisty. Przekierowanie wewnątrz aplikacji, zwane przekazaniem (forward), może posłużyć do spreparowania adresu, który przejdzie kontrolę dostępu, a potem przeniesie atakującego do funkcji uprzywilejowanych ^[2]. Wśród przykładów MITRE jest też CVE-2020-11053, obejście mechanizmu OAuth2 za pomocą zakodowanych w HTML znaków białych ^[1].

Sam open redirect nie daje dostępu do serwera. Jego wartość dla atakującego rośnie w połączeniu z socjotechniką i innymi błędami.

W WordPressie

WordPress ma w rdzeniu dwie funkcje przekierowania. wp_safe_redirect() korzysta z wp_redirect(), ale dodaje kontrolę adresu ^[3]. Wykonuje bezpieczne, lokalne przekierowanie: sprawdza, czy adres bezwzględny prowadzi do dozwolonego hosta, a jeśli nie, kieruje do wp-admin w adresie witryny ^[3]. Dokumentacja wprost podaje, że zapobiega to złośliwym przekierowaniom na inny host ^[3].

Pod spodem działa wp_validate_redirect(). Domyślnie dopuszcza tylko hosta z adresu home_url(), a listę można rozszerzyć filtrem allowed_redirect_hosts ^[4]. Funkcja obsługuje też adresy zaczynające się od dwóch ukośników, które przeglądarka traktuje jako adresy bez protokołu i prowadzą do obcej domeny ^[4].

Błędy open redirect w ekosystemie WordPressa pojawiają się głównie we wtyczkach, które przyjmują adres powrotu w parametrze i przekazują go do wp_redirect(); zob. podatność we wtyczce. Po wp_safe_redirect() trzeba wywołać exit, bo funkcja nie kończy wykonania sama ^[3].

$cel = isset( $_GET['wroc'] ) ? wp_unslash( $_GET['wroc'] ) : '';
wp_safe_redirect( wp_validate_redirect( $cel, home_url( '/' ) ) );
exit;

Open redirect trzeba odróżnić od złośliwego przekierowania. W złośliwym przekierowaniu atakujący zmienił już pliki albo bazę strony i przekierowuje wszystkich odwiedzających. W open redirect strona jest nietknięta, a przekierowanie działa tylko dla spreparowanego linku.

Jak się bronić

OWASP zaleca w pierwszej kolejności unikanie przekierowań sterowanych danymi użytkownika ^[2]. Gdy są potrzebne, użytkownik powinien podawać krótką nazwę, identyfikator albo token, który serwer zamienia na pełny adres docelowy ^[2]. Inne metody to lista zaufanych hostów oraz strona pośrednia informująca, że użytkownik opuszcza witrynę ^[2]. MITRE wymienia podobne środki: walidację z listą dozwolonych adresów, stronę ostrzegawczą z odpowiednim opóźnieniem, mapowanie stałych identyfikatorów na zatwierdzone adresy, jednorazowy nonce w żądaniu przekierowania oraz zaporę aplikacyjną WAF wykrywającą wzorce ataku ^[1]. MITRE zastrzega, że ochronę tokenem jednorazowym może obejść XSS (Cross-Site Scripting) na tej samej stronie ^[1]. Najprostszy bezpieczny wzorzec OWASP to przekierowanie pod adres zapisany na stałe w kodzie, bez udziału danych od użytkownika ^[2].

Historia i przykłady

Niebezpiecznik opisał 13 kwietnia 2010 roku open redirect w serwisie YouTube, wykorzystany w demonstracji phishingu ^[5]. Wcześniej ten sam serwis pisał o podobnym błędzie w Nasza-Klasa.pl ^[5]. Parametr przekierowania w adresie YouTube prowadził do fałszywej strony weryfikacji wieku z formularzem logowania ^[5]. Autor demonstracji zanotował ponad 25 tysięcy wejść, a formularz wypełniło prawie 6 tysięcy osób ^[5]. Google zablokowało użyte przekierowanie, ale luka pozwalała tworzyć kolejne ^[5]. Ten przypadek dobrze pokazuje, dlaczego blokowanie pojedynczych adresów nie zastępuje poprawki w kodzie.

Sekurak 23 lipca 2018 roku opisał błąd w aplikacji desktopowej Google Chat znaleziony przez Michała Bentkowskiego ^[6]. Aplikacja nie miała paska adresu, więc po przekierowaniu użytkownik nie mógł sprawdzić, na jakiej domenie jest, i mógł trafić na fałszywy panel logowania Google ^[6]. Google wypłaciło za zgłoszenie 7500 dolarów w ramach programu bug bounty ^[6]. Według Sekuraka na wysokość nagrody wpłynęła możliwość doprowadzenia do wykonania kodu w systemie operacyjnym użytkownika ^[6]. Przykład pokazuje, że waga open redirect zależy od kontekstu: w przeglądarce użytkownik widzi adres, w aplikacji bez paska adresu już nie.