Na tropie błędów. Przewodnik hakerski. Peter Yaworski
Читать онлайн книгу.
wniosek o pomoc przez URL /hc/en-us/requests/new.) Niestety jednak każdy mógł utworzyć swoje konto Zendesk i przekazać je do parametru /redirect_to_account?state=. Utworzone konto Zendesk mogło następnie przekierowywać na inną stronę nienależącą do Zendesk bądź HackerOne. Ponieważ Zendesk zezwalał na przekierowania między kontami bez pośredniczących stron, użytkownik mógł zostać wysłany na niezaufaną stronę bez ostrzeżenia. Jako rozwiązanie HackerOne zaczął identyfikować linki zawierające zendesk_session jako zewnętrzne, a tym samym wyświetlać ostrzeżenie po ich kliknięciu.
W celu potwierdzenia tej podatności, haker Mahmoud Jamal stworzył konto na platformie Zendesk z subdomeną http://compayn.zendesk.com. Następnie dodał następujący kod JavaScript do pliku nagłówka, używając edytora motywów Zendesk, który pozwalał administratorom na dostosowywanie wyglądu ich strony:
<script>document.location.href = <<http://evil.com>>;</script>
Używając tego kodu, Jamal instruował przeglądarkę, by odwiedziła http://evil.com. Tag <script> oznacza kod JavaScript, a document odnosi się do całego dokumentu HTML, który Zendesk zwraca jako informację dla strony internetowej. Kropki i nazwy następujące po document są jego właściwościami. Właściwości zawierają informację i wartości, które albo opisują obiekt, albo mogą być manipulowane, by zmienić obiekt. Możesz zatem użyć właściwości location do kontroli strony internetowej, którą Twoja przeglądarka wyświetla i użyć podwłaściwości href (która jest właściwością location) do przekierowania przeglądarki do zdefiniowanej strony. Odwiedzenie następującego linku przekierowywało ofiary do subdomeny Zendesk należącej do Jamala, która zawierała skrypt przekierowujący ich przeglądarki na http://evil.com:
https://hackerone.com/zendesk_session?locale_id=1&return_to=https: //support.hackerone.com/ping/redirect_to_account?state=compayn:/
Ponieważ ten link zawiera domenę hackerone.com, pośrednicząca strona nie wyświetlała się, a użytkownik nie wiedział, że strona, którą odwiedza, jest niebezpieczna. Co ciekawe, Jamal wcześniej zgłosił problem z brakującą stroną pośredniczącą do Zendeska, lecz zgłoszenie zostało zignorowane. Instynktownie nie zaprzestał poszukiwań i w końcu odkrył atak przez JavaScript, który przekonał HackerOne do wypłacenia nagrody.
Wnioski
Gdy poszukujesz podatności, miej na uwadze fakt, iż zewnętrzne serwisy, których używają strony, otwierają nowe miejsca na poszukiwania. Podatność na stronie HackerOne istniała tylko dzięki ich współpracy z Zendesk-iem.
Dodatkowo, gdy znajdziesz błąd, mogą zdarzyć się przypadki, gdzie Twoje uwagi dotyczące bezpieczeństwa nie będą zrozumiane przez osobę reagującą na Twoje zgłoszenie. Z tego powodu przedyskutujemy zgłoszenia znalezionych błędów w rozdziale 19, który uszczegóławia to, co powinieneś dołączyć do raportu, jak budować współpracę z firmami i wszelkie pozostałe informacje. Jeśli popracujesz nad opisem znalezionej podatności w raporcie, Twoje starania pomogą w płynnym rozwiązaniu.
Oprócz tego pojawią się sytuacje, gdy firmy nie zgodzą się z Tobą. W takich przypadkach kontynuuj poszukiwania, tak jak to zrobił Jamal, i sprawdź, czy możesz udowodnić niebezpieczeństwo, łącząc kilka podatności naraz, by zademonstrować ich wpływ.
Podsumowanie
Otwarte przekierowania pozwalają atakującym na odesłanie użytkowników na niebezpieczną stronę bez ich wiedzy. Znajdowanie ich – co już powinieneś wiedzieć – wymaga wnikliwej obserwacji. Parametry do przekierowań mogą być łatwe do znalezienia, jeśli mają nazwy takie jak redirect_to=, domain_name= czy checkout_url=. W pozostałych jednak przypadkach będą to mniej oczywiste nazwy: r=, u= i tak dalej.
Podatność w postaci otwartego przekierowania opiera się na wykorzystaniu zaufania ofiary do serwisu, który zna, podczas gdy jest nabierana na odwiedzenie strony atakującego. Kiedy zauważysz potencjalnie podatne parametry, upewnij się, że przetestowałeś je dokładnie i użyłeś w tym celu znaków specjalnych.
Przekierowanie pośrednie HackerOne’a pokazuje istotę rozpoznawania narzędzi i serwisów, których strony używają, podczas poszukiwań podatności. Pamiętaj, że czasami będziesz musiał być cierpliwy i wyczerpująco opisać zarówno podatność, jak i jej wpływ na testowane strony, by namówić firmę na zaakceptowanie Twojego znaleziska i przyznanie nagrody.
3.
HTTP PARAMETER POLLUTION
HTTP Parameter Pollution (HPP) jest procesem manipulacji tego, w jaki sposób witryna traktuje parametry, które dostaje podczas żądań HTTP. Ta podatność następuje, gdy atakujący wstrzykuje dodatkowe parametry do żądania, a docelowa strona akceptuje je, prowadząc tym samym do nieoczekiwanych wyników. Błędy HPP mogą wystąpić po stronie serwera lub klienta. Jeśli błąd występuje
po stronie klienta, którą jest zazwyczaj Twoja przeglądarka, możesz zobaczyć efekt swoich testów. W wielu przypadkach podatności HPP zależą od tego, w jaki sposób kod po stronie serwera używa wartości przekazanych jako parametry, które są kontrolowane przez atakującego. Z tego powodu szukanie tego rodzaju podatności może wymagać nieco więcej pracy niż w przypadku pozostałych.
W tym rozdziale zaczniemy od poznania ogólnych różnic między HPP po stronie serwera a HPP po stronie klienta. Potem przedstawię trzy przykłady oparte na znanych serwisach społecznościowych, aby zilustrować użycie HPP do wstrzyknięcia parametrów na docelowe strony. Dokładniej mówiąc, dowiesz się, jak wykonywać testy na HPP oraz poznasz miejsca, w których deweloperzy często popełniają pomyłki. Jak zobaczysz, znajdowanie podatności HPP wymaga cierpliwości i kombinowania, ale może być warte starań.
HPP po stronie serwera
W przypadku HPP po stronie serwera, do serwera wysyła się nieoczekiwane informacje w zamiarze otrzymania od niego nieoczekiwanych rezultatów. Kiedy wykonujesz żądanie do strony internetowej, serwer tej strony przetwarza żądanie i zwraca odpowiedź, tak jak omawialiśmy to w rozdziale 1. W niektórych przypadkach serwery nie zwracają zwyczajnie strony internetowej, ale również uruchamiają kod, bazując na informacji, którą otrzymali z odebranego URL-a. Kod ten jest uruchamiany tylko na serwerze, jest więc niewidoczny dla ciebie; możesz zobaczyć wysłaną informację i zwrócony rezultat, lecz pośredniczący kod jest nieosiągalny. W związku z tym możesz jedynie wywnioskować to, co się dzieje. Ponieważ nie widzisz tego, jak kod serwera funkcjonuje, HPP po stronie serwera zależy od Twojej zdolności do identyfikacji potencjalnie podatnych parametrów i eksperymentowania z nimi.
Spójrzmy na przykład: HPP po stronie serwera mógłby wystąpić wtedy, gdy Twój bank inicjowałby przelew za pomocą swojej strony przez akceptację parametrów URL, które są przetwarzane na jego serwerach. Wyobraź sobie, że mógłbyś zrobić przelew przez wpisanie trzech wartości w trzech parametrach URL: from, to i amount. Parametry te określają kolejno numer konta, z którego ma zostać wykonany przelew, numer konta docelowego i kwotę pieniędzy do przesłania. Adres URL z tymi parametrami, który przesyła 5000 $ z konta o numerze 12345 na konto 67890, wyglądałby następująco:
https://www.bank.com/transfer?from=12345&to=67890&amount=5000
Możliwe jest, że bank zakładałby, że otrzyma tylko jeden parametr from. Co jednak jeśli otrzyma dwa, tak jak tutaj:
https://www.bank.com/transfer?from=12345&to=67890&amount=5000&from=ABCDEF
Ten URL jest umyślnie zbudowany tak samo jak poprzedni z tą różnicą, że zawiera