Na tropie błędów. Przewodnik hakerski. Peter Yaworski

Чтение книги онлайн.

СКАЧАТЬ 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 dodatkowy parametr from, który określa inne konto nadawcy, ABCDEF. W tej sytuacji atakujący mógłby wysłać dodatkowy parametr w nadziei, że aplikacja zweryfikuje transfer, używając pierwszego parametru from, ale pobierze pieniądze, używając drugiego. Zatem atakujący byłby w stanie wykonać transfer pieniędzy z konta, do którego nie ma dostępu, jeżeli tylko bank akceptowałby ostatni parametr from, który otrzymał. Zamiast wysyłać 5000 $ z konta 12345 na 67890, kod serwera użyłby drugiego parametru i wysłał pieniądze z konta ABCDEF na 67890.

      Kiedy serwer dostaje kilkukrotne parametry z tą samą nazwą, może odpowiedzieć na wiele sposobów. Na przykład PHP i Apache używają ostatniego wystąpienia, Apache Tomcat używa pierwszego, ASP i IIS używają wszystkich i tak dalej. Dwóch badaczy, Luca Carettoni i Stefano di Paola, udostępnili dokładną prezentację wielu różnic między technologiami serwerów podczas konferencji AppSec EU 09; informacja ta jest teraz dostępna na stronie OWASP na https://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf (zob. slajd 9). W wyniku tego nie ma jednego gwarantowanego procesu do obsługi wielokrotnych parametrów z tą samą nazwą, więc znalezienie podatności HPP wymaga nieco kombinowania, by przekonać się o tym, jak działa strona, którą sprawdzasz.

      Przykład z bankiem używa parametrów, które są oczywiste. Czasami jednak podatności HPP objawiają się jako rezultat ukrytego zachowania po stronie serwera, wynikającego z kodu, który nie jest bezpośrednio widoczny. Powiedzmy na przykład, że Twój bank zadecydował ulepszyć sposób, w jaki przetwarza przelewy, i zmienia kod w backendzie tak, aby nie używał parametru from z URL-a. Tym razem bank użyje dwóch parametrów, jednego do konta, na które ma zostać wykonany przelew, a drugiego do kwoty do przelania. Przykładowy link mógłby wyglądać tak:

      https://www.bank.com/transfer?to=67890&amount=5000

      Zazwyczaj kod na serwerze byłby dla nas zagadką, lecz ze względu na potrzeby tego przykładu wiemy, że kod Ruby serwera (nadzwyczaj brzydki i bezużyteczny) wygląda następująco:

      user.account = 12345

      def prepare_transfer(

params)

      

params << user.account

      

transfer_money(params) #user.account (12345) becomes params[2]

      end

      def transfer_money(params)

      

to = params[0]

      СКАЧАТЬ