otwarte przekierowania jako zbyt małe niebezpieczeństwo do wypłacenia wynagrodzenia. The Open Web Application Security Project (OWASP), który stanowi społeczność skupioną wokół bezpieczeństwa aplikacji, prowadzi listę najbardziej krytycznych wad bezpieczeństwa. W edycji z 2017 roku swojej listy top dziesięciu podatności całkowicie usunęli z niej otwarte przekierowania.
Mimo że otwarte przekierowania są mało krytycznymi podatnościami, stanowią świetny materiał do nauki tego, w jaki sposób przeglądarka wykonuje przekierowania. W tym rozdziale nauczysz się, jak wykorzystać otwarte przekierowania i jak zidentyfikować kluczowe parametry, posiłkując się trzema przykładami raportów błędu.
Jak działają otwarte przekierowania?
Otwarte przekierowania pojawiają się wtedy, gdy deweloper błędnie zaufa wejściu kontrolowanemu przez potencjalnego atakującego i przekierowuje użytkownika na inną stronę, zazwyczaj za pomocą parametrów URL, znaczników odświeżających HTML <meta> lub własności lokalizacji okna DOM.
Wiele stron celowo odsyła użytkowników na inne strony, umieszczając docelowy adres URL jako parametr w oryginalnym URL-u. Aplikacja wykorzystuje ten parametr, żeby powiedzieć wyszukiwarce, by wysłała żądanie GET do docelowego adresu URL. Na przykład załóżmy, że Google ma możliwość przekierowywania użytkowników do Gmaila przez odwiedzenie następującego adresu URL:
https://www.google.com/?redirect_to=https://www.gmail.com
W tym przypadku, gdy odwiedzisz ten link, Google otrzyma żądanie HTTP GET i użyje parametru redirect_to, by zdecydować, gdzie przekierować Twoją przeglądarkę. Po zrobieniu tego serwery Google zwracają odpowiedź HTTP z kodem statusu instruującym Twoją przeglądarkę do przekierowania użytkownika. Zazwyczaj jest to kod 302, ale w niektórych przypadkach może to być 301, 303, 307 lub 308. Wszystkie te kody HTTP mówią Twojej przeglądarce, że strona została znaleziona; jednakże kod również informuje przeglądarkę, by wykonała żądanie GET do adresu znalezionego w wartości parametru redirect_to, https://www.google.com/, który jest oznaczony w nagłówku odpowiedzi HTTP Location. Nagłówek Location określa, gdzie przekierować żądanie GET.
Teraz przypuśćmy, że atakujący zmienił oryginalny link na poniższy:
https://www.google.com/?redirect_to=https://www.attacker.com
Jeśli Google nie weryfikuje, czy parametr redirect_to należy do jednego z jego prawowitych serwerów, gdzie zazwyczaj odsyła użytkowników, atakujący mógłby podmienić wartość parametru z jego własnym URL-em. W wyniku tego odpowiedź HTTP mogłaby instruować Twoją przeglądarkę do wysłania żądania GET na stronę https://www.<attacker>.com/. Kiedy atakujący wreszcie przyciągnął Cię na swoją złośliwą stronę, jest w stanie wykonać na Tobie kolejne ataki.
Gdy poszukujesz podatności tego rodzaju, miej na uwadze parametry URL włączające pewne nazwy, takie jak url=, redirect=, next= i tym podobne, mogące wskazywać na URL, do którego użytkownicy będą przekierowywani. Również pamiętaj o tym, że parametry nie będą zawsze oczywiście nazwane; parametry będą się różniły od siebie na różnych stronach, a nawet w obrębie jednej. W niektórych przypadkach parametry mogą być oznaczone tylko jednym znakiem, takim jak r= czy u=.
W dodatku do ataków bazujących na parametrach, tagi HTML <meta> i JavaScript mogą również przekierowywać przeglądarkę. Tagi <meta> HTML mówią przeglądarce, aby odświeżyć stronę i wykonać żądanie GET na adres URL zdefiniowany w atrybucie content. Oto jak może wyglądać jeden z nich:
<meta http-equiv="refresh" content="0; url=https://www.google.com/">
Atrybut content definiuje, jak przeglądarka wykona żądanie HTTP, na dwa sposoby. Po pierwsze, content określa, jak długo przeglądarka czeka przed wysłaniem żądania HTTP pod wskazany adres; w tym przypadku 0 sekund. Po drugie, atrybut content wyznacza parametr URL strony, do której wysyła żądanie GET; w tym przypadku http://www.google.com. Atakujący mogą wykorzystać te zachowania w sytuacjach, w których kontrolują atrybut content w tagu <meta> lub dodać własny tag przez inną podatność.
Atakujący może również użyć kodu JavaScript, by przekierować użytkowników przez modyfikację właściwości location okna przez obiektowy model dokumentu (DOM – Document Object Model). DOM jest interfejsem programowania dla dokumentów HTML i XML, który pozwala deweloperom na modyfikowanie struktury, stylów i zawartości strony internetowej. Ponieważ właściwość location wskazuje, gdzie żądanie powinno zostać przekierowane, przeglądarka niezwłocznie zinterpretuje szkodliwy JavaScript i przekieruje do określonego adresu URL. Atakujący może modyfikować własność location okna, używając jednego z wybranych skryptów:
window.location = https://www.google.com/
window.location.href = https://www.google.com
window.location.replace(https://www.google.com)
Zazwyczaj możliwość zmiany wartości window.location pojawia się jedynie tam, gdzie atakujący może wykonać kod JavaScript, przez podatność cross-site scripting (XSS), albo tam, gdzie strona celowo pozwala użytkownikom decydować o adresie URL do przekierowania, podobnie jak w podatności serwisu HackerOne omawianej później w tym rozdziale, na stronie 16.
Kiedy szukasz podatności na otwarte przekierowanie, najczęściej będziesz monitorował swoją historię proxy, szukając żądań GET wysłanych do strony, którą testujesz.
Otwarte przekierowanie przy instalacji motywu Shopify
Poziom trudności: Niski
URL: https://apps.shopify.com/services/google/themes/preview/ supply–blue?domain_name=<dowolnadomena>
Źródło: https://www.hackerone.com/reports/101962/
Data zgłoszenia: 25 listopada 2015
Nagroda: 500 $
Pierwszy przykład podatności na otwarte przekierowania, który poznasz, został znaleziony na platformie Shopify pozwalającej użytkownikom tworzyć sklepy internetowe. Shopify zezwala administratorom na dostosowywanie wyglądu swoich sklepów przez zmianę ich motywów. Jako część tej funkcjonalności, Shopify zaoferowało możliwość sprawdzenia wyglądu motywu przez przekierowanie właściciela sklepu na adres URL. Przekierowujący URL prezentował się następująco:
https://apps.shopify.com/services/google/themes/preview/supply–blue?domain_name=attacker.com
Parametr domain_name na końcu URL-a przekierowywał domenę sklepu użytkownika i dodawał /admin na końcu adresu. Shopify spodziewał się, że parametr domain_name zawsze będzie adresem sklepu użytkownika i nie weryfikował, czy należy do serwisu. W rezultacie atakujący mógł wykorzystać parametr do przekierowania ofiary na stronę http:/<attacker>.com/admin/, gdzie mógł podjąć się kolejnych ataków.
Wnioski
Nie wszystkie podatności są skomplikowane.
