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#
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