Open redirect to luka, w której aplikacja webowa pobiera URL docelowy z niezweryfikowanych danych wejściowych użytkownika - zwykle z parametru zapytania takiego jak ?next= lub ?url= - i przekazuje tam przeglądarkę bez sprawdzenia. Link zaczyna się na domenie, której ofiara ufa, więc przechodzi inspekcję, a następnie po cichu sprowadza ją gdzie indziej. Poprawką nie jest przestać przekierowywać. Jest nią przestać pozwalać żądaniu decydować, dokąd prowadzi przekierowanie.
To rozróżnienie ma znaczenie, bo przekierowania są wszędzie i większość z nich jest w porządku. Zalogowanie się i odbicie z powrotem na stronę, której chciałeś, przekazanie do dostawcy płatności, callback OAuth - wszystko normalne, wszystko to przekierowania. Błąd, skatalogowany jako CWE-601 i zgrupowany pod broken access control w OWASP Top 10, to konkretnie przypadek, w którym cel pochodzi z danych kontrolowanych przez użytkownika i nic go najpierw nie waliduje. Atakujący podsuwa własny URL, zaufana witryna przekazuje do niego, a zaufanie przenosi się wraz z kliknięciem.
Spędzam dni na ścieżce przekierowań, więc to temat, na który mam zdanie. Krótkie linki są z definicji przekierowaniami, co czyni pytanie "czy skracacz to po prostu open redirect?" uczciwym - a odpowiedź, gdy zrobiono to dobrze, to czyste nie. Dochodzimy tam poniżej. Jeśli mechanika przekierowań jest dla Ciebie nowa, rodzaje przekierowań to elementarz, a jak działają skracacze URL omawia podstawy warstwy przekierowań.
Czym właściwie jest open redirect
Sprowadź to do mechanizmu. Strona przyjmuje parametr nazywający, dokąd dalej, i używa go w przekierowaniu HTTP bez potwierdzenia, że wskazuje gdzieś dozwolone.
https://trusted.example/login?next=https://evil.example/fake-login
Ofiara widzi trusted.example na początku i klika. Po zalogowaniu aplikacja odczytuje next i wystawia przekierowanie do evil.example. Przeglądarka słucha, bo przekierowanie to po prostu nagłówek Location i status 3xx - specyfikacja HTTP definiuje to zachowanie wprost, a przeglądarka nie ma jak wiedzieć, że ten konkretny cel jest wrogi. Użytkownik, obserwując, jak pasek adresu zmienia się już po tym, jak zaufał linkowi, często tego nie zauważa.
OWASP opisuje główne niebezpieczeństwo dosadnie: nazwa serwera w zmodyfikowanym linku jest identyczna z oryginalną witryną, co użycza wiarygodności złośliwemu przekierowaniu. Luką nie jest to, że witryna przekierowuje. Jest nią to, że to ktoś z zewnątrz wybrał cel.
Dlaczego "nieszkodliwe" przekierowanie jest realnym zagrożeniem
Odruchem jest wzruszenie ramionami: no przenosi kogoś na inną witrynę, gdzie tu szkoda. Szkodą jest pożyczone zaufanie, a ono skaluje się.
Phishing to sztandarowe zastosowanie. Link, który zaczyna się od banku, logowania do SaaS lub portalu rządowego, śmiga obok szybkiego sprawdzenia wzrokiem, które robi większość ludzi, i obok zaskakującej liczby zautomatyzowanych filtrów, które oglądają tylko wiodącą domenę. Ofiara trafia na idealny co do piksela falsyfikat strony logowania, której oczekiwała, na domenie, która wyglądała poprawnie jeden przeskok temu, i wpisuje hasło. Żadnego złośliwego oprogramowania, żadnego egzotycznego ładunku - tylko przekierowanie i klon.
Robi się gorzej, gdy przekierowania siedzą w pobliżu uwierzytelniania. Open redirect w przepływie OAuth może wyciekać kod autoryzacyjny lub token do kontrolowanego przez atakującego redirect_uri, co eskaluje "drobny" błąd w pełne przejęcie konta. Dlatego open redirecty są podstawą raportów bug-bounty, a nie przypisem. Ta sama sztuczka pierze też reputację: spamerzy i operatorzy złośliwego oprogramowania uwielbiają odbijać się przez zaufaną domenę, bo przepuszcza to ich prawdziwy link obok list blokad. Szerszą kategorię omawiamy w liście kontrolnej bezpieczeństwa skracaczy URL, a perspektywę zaufania od strony odwiedzającego w czy skracacze URL są bezpieczne.
Jak zapobiegać open redirectom
Istnieje hierarchia poprawek, a na jej szczycie znajduje się ta, która faktycznie kończy problem. Ściąga OWASP je porządkuje, a tę kolejność warto stosować.
- W ogóle nie pobieraj URL z żądania. Spraw, by klient wysyłał krótką nazwę, identyfikator lub token, i rozwiązuj go do pełnego celu po stronie serwera. OWASP nazywa to najwyższym stopniem ochrony, bo przychodzące żądanie nie może już nazwać dowolnego celu. Jeśli ten wzorzec brzmi znajomo, to słusznie: tak właśnie działa skracacz URL.
- Lista dozwolonych, nie lista zablokowanych. Gdy musisz przyjąć cel, sprawdź go względem listy zaufanych hostów lub rygorystycznego wyrażenia regularnego. Lista dozwolonych zawodzi bezpiecznie - wszystko, co nie jest wprost dopuszczone, zostaje odrzucone. Lista zablokowanych zawodzi otwarcie, a atakującym płaci się za znajdowanie wpisów, o których zapomniałeś.
- Parsuj rygorystycznie. Odrzucaj URL względne względem protokołu (
//evil.example), normalizuj ukośniki wsteczne, dekoduj przed walidacją i traktuj host - nie tylko prefiks ciągu - jako rzecz do sprawdzenia. Większość obejść filtrów żyje w leniwym parsowaniu. - Pokaż stronę pośrednią jako zabezpieczenie. Jeśli przekierowanie na zewnętrzną witrynę jest nieuniknione, prowadź je przez stronę, która nazywa cel i prosi użytkownika o potwierdzenie. To tarcie, ale zamienia ciche przekierowanie w świadome.
Powracającym motywem jest to, że bezpieczne przekierowania decyduje serwer, na podstawie danych, którym serwer już ufa - nigdy jakikolwiek ciąg, który przybył w zapytaniu.
Jeśli budujesz przekierowania w produkcie i wolisz nie być właścicielem tego trybu awarii, platforma deweloperska Elido z założenia mapuje kody na cele po stronie serwera - zacznij od szybkiego startu API i nigdy więcej nie sklejaj ręcznie parametru ?url=.
Dlaczego krótkie linki są obroną, a nie błędem
Oto część, która zaskakuje ludzi. Poprawnie zbudowany skracacz URL jest podręcznikową implementacją poprawki open redirect numer jeden według OWASP.
Gdy krótki link jest tworzony, jego cel jest walidowany i zapisywany po stronie serwera, powiązany z krótkim kodem. Gdy ktoś odwiedza, warstwa przekierowań wyszukuje ten kod i przekazuje do zapisanego celu. Cel nigdy nie pochodzi z przychodzącego żądania - odwiedzający nie może dopisać ?url= i nagiąć linku gdzie indziej, bo nie ma takiego parametru do naginania. To dokładnie to mapowanie token-do-URL, które zaleca OWASP, działające w produkcji miliony razy dziennie. Architektonicznie żyje to w naszej warstwie przekierowań na brzegu sieci, a budżet opóźnień, który za to płaci, jest tematem osiągania p95 poniżej 15 ms dla przekierowań.
Szczere zastrzeżenie: skracacz nadal może być nadużywany, tyle że nie przez open redirect. Jeśli platforma pozwala każdemu wybijać linki do czegokolwiek bez skanowania czy moderacji, atakujący użyją reputacji jej domeny, by maskować własne złośliwe cele - dlatego odpowiedzialne skracacze skanują cele i egzekwują polityki przeciw nadużyciom. To problem moderacji treści, odrębny od błędu walidacji danych wejściowych, o którym jest ten artykuł, i warto tego nie mylić. Powiązana praktyka celowego ukrywania celu jest omówiona w cloaking linków i maskowanie URL wyjaśnione, a socjotechniczny kuzyn tego wszystkiego - wrogie kody QR - w czy kody QR są bezpieczne.
Wniosek w jednym zdaniu
Jeśli Twój kod odczytuje cel z żądania i przekierowuje do niego, masz open redirect czekający na znalezienie. Mapuj zamiast tego identyfikator na cel po stronie serwera, dodawaj do listy dozwolonych wszystko, czego nie da się uniknąć pobrania z wejścia, i parsuj, jakbyś spodziewał się ataku. Przekierowania nie są ryzykiem. Jest nim pozwalanie żądaniu wybierać, dokąd prowadzą. Różnica między 301 a 302 w 301 kontra 302 przekierowania to przypis obok tej jednej zasady.
Powiązane na blogu
Najczęściej zadawane pytania
Czym jest luka typu open redirect?
Open redirect to błąd, w którym aplikacja webowa kieruje użytkowników na URL docelowy pobrany z niezweryfikowanych danych wejściowych, zwykle z parametru zapytania takiego jak ?next= lub ?url=. Ponieważ link zaczyna się na zaufanej domenie, przeglądarka ofiary i wszelkie filtry skanujące linki traktują go jako bezpieczny, ale aplikacja następnie przekazuje go do dowolnej witryny wskazanej przez parametr - w tym do witryny atakującego. Jest klasyfikowany jako CWE-601 i mieści się pod broken access control w OWASP Top 10. Błędem jest brakujące sprawdzenie, a nie samo przekierowanie.
Dlaczego open redirect jest niebezpieczny, skoro tylko przenosi Cię na inną witrynę?
Bo niebezpieczeństwem jest zaufanie, którego użycza domena startowa. Link phishingowy w postaci https://trusted-bank.example/login?next=evil.example przechodzi test oka, przeżywa wiele filtrów pocztowych i sprowadza ofiarę na przekonującą fałszywą stronę logowania - a wszystko to wyglądając, jakby pochodził z prawdziwego banku. Open redirect łączy się też w większe ataki: może wyciekać kody autoryzacyjne lub tokeny OAuth, gdy cel przekierowania jest kontrolowany przez atakującego, zamieniając błąd o niskiej istotności w przejęcie konta. Przekierowanie jest mechanizmem dostarczania, a nie całym exploitem.
Czy skracacze URL to luka typu open redirect?
Nie, nie wtedy, gdy są zbudowane poprawnie - i to właśnie jest sedno. Open redirect pobiera dowolny cel z danych wejściowych użytkownika w czasie żądania i przekazuje do niego bez walidacji. Krótki link mapuje stały kod na cel, który został ustawiony i zapisany po stronie serwera w chwili tworzenia linku; cel przekierowania nigdy nie pochodzi z przychodzącego żądania. To mapowanie po stronie serwera jest dokładnie tą obroną, którą OWASP zaleca przeciwko open redirectom. Skracacz staje się problemem tylko wtedy, gdy pozwala niezweryfikowanym użytkownikom tworzyć linki do czegokolwiek i użycza im reputacji domeny, którą mogą nadużyć - co jest kwestią nadużyć i moderacji, a nie błędem open redirect.
Jak zapobiegać lukom typu open redirect?
Najsilniejszą poprawką jest w ogóle nigdy nie przyjmować URL docelowego z żądania. Spraw, by klient wysyłał krótką nazwę, identyfikator lub token, i mapuj go na pełny cel po stronie serwera - taki sam model, jakiego używa skracacz URL. Gdy naprawdę musisz przyjąć URL, waliduj go względem listy dozwolonych zaufanych hostów, a nie listy złych, odrzucaj wszystko, co nie jest ścieżką względną ani zatwierdzoną domeną, i bądź rygorystyczny przy parsowaniu, aby sztuczki takie jak //evil.example czy ukośniki wsteczne nie przemknęły. W ostateczności prowadź przekierowanie przez stronę pośrednią, która pokazuje cel, zanim wyśle użytkownika dalej.
Jak atakujący wykorzystują open redirect?
Znajdują punkt końcowy, który odzwierciedla parametr URL w przekierowaniu, następnie tworzą link na zaufanej domenie z własną witryną w tym parametrze i rozpowszechniają go e-mailem, reklamą lub wiadomością. Warianty obejmują kodowanie ładunku w URL, aby ominąć słabe filtry, używanie URL względnych względem protokołu, jak //attacker.example, wykorzystywanie tylko części hosta przy zachowaniu wyglądającej legalnie ścieżki oraz nadużywanie obsługi redirect_uri w OAuth do przechwytywania tokenów. Wspólnym wątkiem jest to, że ofiara widzi i ufa pierwszej domenie, a drugiej nie widzi, dopóki nie jest za późno.
Czy open redirect to luka o wysokiej czy niskiej istotności?
Sam w sobie open redirect jest często oceniany jako niski do średniego, bo nie kompromituje bezpośrednio serwera - przenosi użytkowników gdzie indziej. Ale istotność zależy od tego, w co się łączy. W pobliżu przepływu uwierzytelniania może wyciekać tokeny OAuth i prowadzić do przejęcia konta, co jest wysoką istotnością; jako pomoc w phishingu może powodować realną utratę poświadczeń, której wynik CVSS nie uchwyci. Traktuj go według wpływu w kontekście, a nie według podstawowej etykiety, i naprawiaj niezależnie: remediacja jest tania, a potencjał nadużyć nie.
Wypróbuj Elido
Wklej URL, otrzymaj krótki link
Bez rejestracji. Link działa 30 dni. Zarejestruj się, aby zachować go na zawsze.
Za darmo, bez rejestracji · 2 dziennie