Na tropie błędów. Przewodnik hakerski. Peter Yaworski
Читать онлайн книгу.
komunikację z żądanym źródłem. Na przykład metoda CONNECT może mieć dostęp do stron, które używają HTTPS przez proxy.
Metoda OPTIONS wysyła żądanie do serwera o informację o dostępnych możliwościach komunikacji. Na przykład, używając OPTIONS, możesz dowiedzieć się, czy serwer akceptuje zapytania GET, POST, PUT, DELETE lub OPTIONS. Ta metoda nie wskaże jednak, czy serwer akceptuje zapytania HEAD lub TRACE. Przeglądarki internetowe automatycznie wysyłają ten rodzaj żądania, gdy zauważą specyficzny rodzaj zawartości, taki jak application/json. Metoda OPTIONS, należąca do mechanizmu preflighted requests, jest omówiona dokładniej w rozdziale 4, gdyż służy jako ochrona przed atakami CSRF.
Protokół HTTP jest bezstanowy
Żądania HTTP są bezstanowe, co oznacza, że każde wysłane żądanie do serwera jest traktowane jako całkowicie nowe. Serwer nie zna historii komunikacji z Twoją przeglądarką, kiedy dobiera żądanie. Dla większości stron jest to problematyczne, ponieważ chcą one pamiętać kim jesteś. Bez tego musiałbyś wpisywać swoją nazwę użytkownika i hasło za każdym razem, kiedy prześlesz żądanie HTTP. Oznacza to również, że wszystkie dane wymagane do wykonania żądania HTTP musiałyby zostać przeładowane z każdym żądaniem, które klient wyśle do serwera.
Do objaśnienia tego mylącego konceptu rozważ następujący przykład: jeśli Ty i ja prowadzilibyśmy bezstanową konwersację, przed wypowiedzeniem jakiegokolwiek zdania musielibyśmy zacząć od „Nazywam się Peter Yaworski; przed chwilą rozmawialiśmy o hakowaniu”. Wtedy, musiałbyś przeładować wszystkie informacje dotyczące naszej dyskusji o hakowaniu. Pomyśl tylko co Adam Sandler musiał robić dla Drew Barrymore każdego poranka w 50 Pierwszych Randkach (jeśli nie widziałeś tego filmu, to powinieneś).
W celu uniknięcia konieczności wysyłania swojej nazwy użytkownika razem z hasłem dla każdego żądania HTTP strony internetowe korzystają z plików cookies lub podstawowej autoryzacji, które omówimy szczegółowo w rozdziale 4.
UWAGA
Specyfika tego, w jaki sposób dane są kodowane przy użyciu base64, jest poza zakresem tej książki, prawdopodobnie jednak napotkasz zawartość zakodowaną przez base64 podczas hakowania. Jeśli tak, powinieneś ją rozszyfrować. Zapytanie w Google „base64 decode” powinno dostarczyć Ci wystarczającej liczby metod i narzędzi do wykonania tej czynności.
Podsumowanie
Powinieneś teraz już wiedzieć, jak w podstawowy sposób działa komunikacja z serwerami webowymi. Dokładniej mówiąc, dowiedziałeś się tego, co się dzieje, kiedy wpisujesz adres strony w pasek adresu przeglądarki: jak przeglądarka tłumaczy to na domenę, w jaki sposób domena jest kojarzona z adresem IP oraz jak żądanie HTTP jest wysyłane na serwer.
Dowiedziałeś się również, jak Twoja przeglądarka tworzy żądania i renderuje odpowiedzi oraz jak żądania HTTP pozwalają klientom na komunikację z serwerami. Dodatkowo dowiedziałeś się o tym, że podatności wynikają z podejmowania przez kogoś niezamierzonych akcji i otrzymywania informacji w zamyśle niedostępnych dla niego. Poznałeś także programy bug bounty, które wynagradzają hakerów za odkrycia podatności w zabezpieczeniach i zgłaszanie ich do właścicieli stron.
2.
OTWARTE PRZEKIEROWANIE
Naszą dyskusję rozpoczniemy podatnościami otwartego przekierowania następującego wtedy, kiedy wybrany cel odwiedza witrynę, która odsyła jego przeglądarkę do innego adresu URL, potencjalnie na zupełnie inną witrynę. Otwarte przekierowanie wykorzystuje zaufanie do danej domeny, aby zwabić ofiary na złośliwą stronę.
Atakom phishingowym może również towarzyszyć przekierowanie, aby nabrać użytkowników na to, że strona, na którą wysyłają informacje, jest zaufana, podczas gdy w rzeczywistości ich informacje trafiają na złośliwą stronę. W połączeniu z innymi atakami otwarte przekierowania mogą pozwolić atakującym na dystrybucję oprogramowania ze złośliwej strony lub kradzież tokenów Oauth (ten temat rozwiniemy w rozdziale 17).
Ponieważ otwarte przekierowania jedynie przenoszą użytkowników, są często uważane za mało niebezpieczne i mogą nie przysługiwać nagrody za ich znalezienie. Na przykład program bug bounty od Google traktuje 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ć