Dane oryginału

Copyright © 2019 by Peter Yaworski. Title of English-language original: Real-World Bug Hunting: A Field Guide to Web Hacking, ISBN 978-1-59327-861-8, published by No Starch Press. Polish-language edition copyright © 2020 by Polish Scientific Publishers PWN Wydawnictwo Naukowe PWN Spółka Akcyjna.  All rights reserved.

Przekład Kacper Paluch

Projekt okładki polskiego wydania Hubert Zacharski na podstawie oryginału

Wydawca Edyta Kawala

Redaktor prowadzący Jolanta Kowalczuk

Redaktor Anna Bogdanienko

Koordynator produkcji Anna Bączkowska

Konsultacja merytoryczna

Kamil Frankowicz

Zastrzeżonych nazw firm i produktów użyto w książce wyłącznie w celu identyfikacji.

Copyright © for the Polish edition by Wydawnictwo Naukowe PWN SA

Warszawa 2020

ISBN 978-83-01-21051-9

eBook został przygotowany na podstawie wydania papierowego z 2020 r., (wyd. I)

Warszawa 2020

Wydawnictwo Naukowe PWN SA

02-460 Warszawa, ul. Gottlieba Daimlera 2

tel. 22 69 54 321, faks 22 69 54 288

infolinia 801 33 33 88

e-mail: pwn@pwn.com.pl; reklama@pwn.pl

www.pwn.pl

O autorze

Haker Peter Yaworski jest samoukiem dzięki hojnemu dzieleniu się wiedzą przez tak wielu hakerów, którzy zjawili się przed nim, również tych, o których mowa w książce. Jest on doświadczonym bug hunterem, który pomógł takim firmom, jak: Salesforce, Twitter, Airbnb, Verizon Media, United States Department of Defense i wielu innym. Obecnie pracuje w Shopify jako inżynier do spraw bezpieczeństwa, czyniąc handel elektroniczny bezpieczniejszym.

O recenzencie merytorycznym

Tsang Chi Hong, znany również jako FileDescriptor, jest pentesterem i bug hunterem. W wolnym czasie pisze bloga o tematyce bezpieczeństwa na https://blog.innerht.ml, lubi słuchać muzyki filmowej.

Spis treści

PRZEDMOWA

PODZIĘKOWANIA

WSTĘP

Dla kogo jest ta książka?

Jak czytać tę książkę?

Co znajdziesz w tej książce?

Zastrzeżenie dotyczące hakowania

1. PODSTAWY BUG BOUNTY

Podatności i Bug Bounty

Klient i serwer

Co się dzieje, kiedy odwiedzasz stronę

Krok 1: Identyfikacja domeny internetowej

Krok 2: Ustalenie adresu IP

Krok 3: Nawiązanie połączenia TCP

Krok 4: Wysyłanie zapytania HTTP

Krok 5: Odpowiedź serwera

Krok 6: Renderowanie odpowiedzi

Żądania HTTP

Metody żądań

Protokół HTTP jest bezstanowy

Podsumowanie

2. OTWARTE PRZEKIEROWANIE

Jak działają otwarte przekierowania?

Otwarte przekierowanie przy instalacji motywu Shopify

Wnioski

Otwarte przekierowanie przy logowaniu do Shopify

Wnioski

Przekierowanie pośrednie na HackerOne

Wnioski

Podsumowanie

3. HTTP PARAMETER POLLUTION

HPP po stronie serwera

HPP po stronie klienta

Przyciski do udostępniania na HackerOne

Wnioski

Anulowanie subskrypcji powiadomień na Twitterze

Wnioski

Web Intents Twittera

Wnioski

Podsumowanie

4. CROSS-SITE REQUEST FORGERY

Uwierzytelnianie

CSRF przez żądanie GET

CSRF przez żądanie POST

Ochrona przed atakami CSRF

Odłączenie Twittera z Shopify

Wnioski

Zmiana stref użytkowników Instacart

Wnioski

Przejęcie konta Badoo

Wnioski

Podsumowanie

5. HTML INJECTION I FAŁSZOWANIE TREŚCI

Wstrzyknięcie formularza na stronie Coinbase

Wnioski

Dodanie kodu HTML w serwisie HackerOne

Wnioski

Dodanie kodu HTML w serwisie HackerOne – część 2

Wnioski

Content spoofing w Within Security

Wnioski

Podsumowanie

6. CARRIAGE RETURN LINE FEED INJECTION

HTTP request smuggling

HTTP response splitting v.shopify.com

Wnioski

HTTP response splitting Twittera

Wnioski

Podsumowanie

7. CROSS-SITE SCRIPTING

Rodzaje podatności XSS

Hurtownia Shopify

Wnioski

Formatowanie walut w Shopify

Wnioski

Stored XSS w mailu

Wnioski

Wyszukiwarka zdjęć Google

Wnioski

Stored XSS w menedżerze tagów Google

Wnioski

United Airlines XSS

Wnioski

Podsumowanie

8. TEMPLATE INJECTION

Template injection po stronie serwera

Template injection po stronie klienta

Template injection w Uberze przez AngularJS

Wnioski

Template Injection w Uberze przez Flask i Jinja2

Wnioski

Dynamiczne renderowanie w Rails

Wnioski

Template injection w Smarty

Wnioski

Podsumowanie

9. SQL INJECTION

Bazy danych

Przeciwdziałanie SQLi

Blind SQLi w Yahoo! Sports

Wnioski

Uber Blind SQLi

Wnioski

SQLi w Drupal

Wnioski

Podsumowanie

10. SERVER-SIDE REQUEST FORGERY

Demonstracja zagrożeń podatności SSRF

Wywoływanie żądań GET vs. POST

Wykonywanie „ślepych” SSRF-ów

Atakowanie użytkowników przy użyciu odpowiedzi SSRF

SSRF w ESEA oraz wysyłanie zapytań o metadane AWS

Wnioski

SSRF wewnętrznego DNS Google

Wnioski

Wewnętrzne skanowanie portów przy użyciu webhooków

Wnioski

Podsumowanie

11. XML EXTERNAL ENTITY

eXtensible Markup Language

Document Type Definition

Zewnętrzny DTD

Wewnętrzny DTD

Encje XML

Jak działają ataki XXE

Dostęp do odczytu w Google

Wnioski

XXE w Facebooku

Wnioski

XXE w Wikiloc

Wnioski

Podsumowanie

12. ZDALNE WYKONANIE KODU

Wykonywanie poleceń shell

Wykonywanie funkcji

Strategie na eskalację zdalnego wykonania kodu

RCE w bibliotece ImageMagick

Wnioski

Algolia RCE na facebooksearch.algolia.com

Wnioski

RCE przez SSH

Wnioski

Podsumowanie

13. PODATNOŚCI W MANUALNEJ OBSŁUDZE PAMIĘCI

Przepełnienie bufora

Odczyt poza granicami bufora

Przepełnienie typu całkowitego w PHP ftp_genlist()

Wnioski

Moduł hotshot w Pythonie

Wnioski

Odczyt poza granicami bufora w Libcurl

Wnioski

Podsumowanie

14. PRZEJĘCIE SUBDOMENY

Jak działają nazwy domen?

Jak działa przejęcie subdomeny?

Przejęcie subdomeny Ubiquiti

Wnioski

Przypisanie Scan.me do Zendesk

Wnioski

Przejęcie subdomeny Shopify Windsor

Wnioski

Przejęcie Snapchata przez Fastly

Wnioski

Przejęcie Legal Robot

Wnioski

Przejęcie Uber SendGrid

Wnioski

Podsumowanie

15. RACE CONDITION

Kilkukrotne zaakceptowanie zaproszenia do HackerOne

Wnioski

Przekroczenie limitu zaproszeń do Keybase

Wnioski

Race condition w płatnościach HackerOne

Wnioski

Race condition w Shopify Partners

Wnioski

Podsumowanie

16. INSECURE DIRECT OBJECT REFERENCE

Szukanie prostych IDOR-ów

Szukanie bardziej złożonych IDOR-ów

Eskalacja uprawnień w Binary.com

Wnioski

Tworzenie aplikacji w Moneybird

Wnioski

Kradzież tokena API w Twitter Mopub

Wnioski

Ujawnianie informacji o klientach ACME

Wnioski

Podsumowanie

17. PODATNOŚCI OAUTH

Przepływ pracy OAuth

Kradzież tokenów OAuth w Slack

Wnioski

Logowanie z domyślnym hasłem

Wnioski

Kradzież tokenów logowania Microsoft

Wnioski

Przechwytywanie tokenów dostępu Facebooka

Wnioski

Podsumowanie

18. PODATNOŚCI W LOGICE I KONFIGURACJI APLIKACJI

Omijanie uprawnień administratora w Shopify

Wnioski

Omijanie zabezpieczeń konta na Twitterze

Wnioski

Manipulacja wartością Signal w HackerOne

Wnioski

Niepoprawne uprawnienia bucketu S3 w HackerOne

Wnioski

Omijanie dwuetapowej weryfikacji GitLab

Wnioski

Ujawnienie informacji o kodzie PHP Yahoo!

Wnioski

Głosowanie w Hacktivity

Wnioski

Dostęp do instalacji pamięci podręcznej PornHub

Wnioski

Podsumowanie

19. POSZUKIWANIE PODATNOŚCI NA WŁASNĄ RĘKĘ

Rekonesans

Enumeracja subdomen

Skanowanie portów

Wykonywanie zrzutów ekranu

Odkrywanie zawartości

Historia błędów

Testowanie aplikacji

Zbiór technologii

Mapowanie funkcjonalności

Znajdowanie podatności

Idąc dalej

Automatyzacja swojej pracy

Sprawdzanie aplikacji mobilnych

Identyfikacja nowej funkcjonalności

Śledzenie plików JavaScript

Poznawanie technologii

Podsumowanie

20. ZGŁASZANIE PODATNOŚCI

Sprawdź zasady programu bug bounty

Dodaj szczegóły; następnie dodaj ich więcej

Sprawdź podatność dwa razy

Twoja reputacja

Szacunek do drugiej strony

Atrakcyjne nagrody

Podsumowanie

A. NARZĘDZIA

Serwery proxy

Enumeracja subdomen

Rekonesans

Zrzuty ekranu

Skanowanie portów

Rozpoznanie aplikacji

Narzędzia do hakowania

Analiza aplikacji mobilnych

Wtyczki do przeglądarki

B. ŹRÓDŁA

Kursy online

Platformy Bug Bounty

Rekomendowane zasoby

Filmy

Rekomendowane blogi

PRZEDMOWA

Najlepszym sposobem nauki jest zwyczajna praktyka. W ten właśnie sposób nauczyliśmy się hakować.

Byliśmy młodzi. Podobnie jak wszyscy hakerzy, którzy przyszli przed nami, oraz ci, którzy przyjdą po nas, byliśmy napędzani niekontrolowaną, płonącą ciekawością odkrywania „jak to działa”. Początkowo graliśmy w gry komputerowe, a w wieku 12 lat rozpoczęliśmy naukę tworzenia własnego oprogramowania. Nauczyliśmy się programować w Visual Basic oraz PHP z książek z biblioteki oraz własnej praktyki.

Z naszą znajomością tworzenia oprogramowania szybko zauważyliśmy, że te umiejętności pozwalają dostrzegać błędy innych programistów. Przeszliśmy z tworzenia do niszczenia, a hacking od tej pory stał się naszą pasją. W celu uczczenia zakończenia szkoły średniej przejęliśmy kanał telewizyjny i wyemitowaliśmy własną reklamę gratulującą naszej klasie ukończenia szkoły. Choć w tamtym momencie było to zabawne, szybko spotkaliśmy się  z konsekwencjami i dowiedzieliśmy się, że nie jesteśmy hakerami, których świat potrzebuje. Zarówno szkole, jak i stacji telewizyjnej nie było do śmiechu, przez co spędziliśmy wakacje, myjąc okna w ramach kary. W college’u zamieniliśmy nasze umiejętności w rentowną firmę konsultacyjną, która w szczytowym momencie miała klientów w sektorach publicznych oraz prywatnych na całym świecie. Nasze doświadczenie hakerskie doprowadziło do powstania firmy HackerOne, którą założyliśmy razem w 2012 roku.  Naszą misją do dziś jest umożliwić każdej firmie na świecie pomyślną  współpracę z hakerami.

Jeśli to czytasz, również masz ciekawość niezbędną do zostania hakerem oraz bug hunterem. Wierzymy, że ta książka będzie wspaniałym przewodnikiem podczas Twojej podróży. Jest wypełniona wartościowymi i prawdziwymi przykładami zgłoszeń podatności bezpieczeństwa, które pochodzą z prawdziwych programów bug bounty, wraz z pomocną analizą i przeglądem dokonanym przez Pete Yaworskiego, autora i znajomego hakera. Podczas nauki będzie Twoim nieocenionym towarzyszem.

Innym powodem, dla którego ta książka jest tak ważna, jest to, że skupia się na zostaniu hakerem wykorzystującym swoje umiejętności w sposób etyczny. Opanowanie sztuki hakowania potrafi być wyjątkowo potężną umiejętnością, która – mamy nadzieję – będzie wykorzystywana w dobrych celach. Najlepsi hakerzy wiedzą, jak nawigować cienką linią oddzielającą dobre od złego. Wielu ludzi potrafi psuć rzeczy, a niektórzy nawet próbują na tym zarabiać. Wyobraź sobie jednak, że możesz uczynić internet bezpieczniejszym, pracować z firmami dookoła świata, a w dodatku na tym zarabiać. Twój talent pozwala utrzymać miliardy ludzi oraz ich dane w bezpiecznym miejscu. Mamy nadzieję, że dążysz właśnie do tego.

Jesteśmy niezmiernie wdzięczni Pete’owi za jego poświęcenie się w dokumentowaniu tego wszystkiego w tak okazały sposób. Chcielibyśmy mieć dostęp do takich materiałów, kiedy zaczynaliśmy. Książka Pete’a to prawdziwa przyjemność w czytaniu, która zawiera informacje niezbędne do rozpoczęcia podróży w hakowaniu.

Udanej lektury i udanego hakowania!

Pamiętaj, aby hakować odpowiedzialnie.

Michiel Prins i Jobert Abma

współzałożyciele HackerOne

PODZIĘKOWANIA

Bez społeczności HackerOne ta książka nigdy by nie powstała. Chcę podziękować dyrektorowi naczelnemu HackerOne, Mårtenowi Mickosowi, który skontaktował się ze mną, kiedy zacząłem pracę nad tą książką. Nieustannie dostarczał mi swoje opinie i pomysły na ulepszenie książki, a nawet zapłacił za profesjonalną okładkę samodzielnie wydanej wersji.

Chcę również podziękować współzałożycielom HackerOne, Michielowi Prinsowi oraz Jobertowi Abmie, którzy przedstawiali sugestie oraz przyczyniali się do powstawania niektórych rozdziałów, kiedy pracowałem nad wczesnymi wersjami tej książki. Jobert dokonał dogłębnej analizy, redagując każdy rozdział, aby dostarczyć informacje zwrotne i spostrzeżenia techniczne. Jego praca zwiększyła moją pewność siebie i nauczyła mnie więcej niż kiedykolwiek zdawałem sobie sprawę, że jest to możliwe.

Ponadto, Adam Bacchus przeczytał książkę pięć dni po dołączeniu do HackerOne, wprowadził poprawki i opisał swoje wrażenia po przeczytaniu zgłoszeń podatności, które pomogły mi w tworzeniu rozdziału 19. HackerOne nigdy nie prosił o nic w zamian. Jedyne czego platforma chciała, to wspieranie społeczności hakerów, czyniąc tę książkę możliwie jak najlepszą.

Byłbym samolubny, gdybym osobno nie podziękował Benowi Sadeghipourowi, Patrikowi Fehrenbachowi, Fransowi Rosenowi, Philippe’owi Harewoodowi, Jasonowi Haddixowi, Arne’owi Swinnenowi, FileDescriptorowi i wszystkim innym, którzy na początku pomagali mi rozmową o hakowaniu, dzielili się swoją wiedzą i zachęcali. Dodatkowo ta książka nie powstałaby bez hakerów, którzy udostępniają swoją wiedzę i upubliczniają błędy, a szczególnie tych, których znalezione błędy wykorzystuję w książce. Dziękuję wam wszystkim.

Wreszcie, nie byłbym w miejscu, w którym jestem dziś, bez wsparcia i miłości ze strony mojej żony i dwóch córek. To właśnie dzięki nim odniosłem sukces w hakowaniu i byłem w stanie dokończyć pisanie tej książki. I oczywiście wielkie podziękowania dla reszty rodziny, szczególnie dla  moich rodziców, którzy odmówili mi kupna systemów Nintendo, gdy dorastałem, a zamiast nich kupowali komputery i powtarzali, że to właśnie one są przyszłością.

WSTĘP

Ta książka wprowadzi Cię do obszernego świata hackingu etycznego lub inaczej procesu odpowiedzialnego odkrywania podatności bezpieczeństwa i zgłaszania ich do właścicieli aplikacji. Kiedy sam zaczynałem naukę hakowania, nie tylko chciałem wiedzieć, jakie podatności hakerzy znajdują, ale również, jak to robią.

Szukałem wszędzie informacji, lecz zawsze pozostawałem z tymi samymi pytaniami:

• Jakie podatności hakerzy znajdują w aplikacjach?

• Jak hakerzy uczyli się o tych podatnościach?

• Jak hakerzy zaczynają infiltrację strony?

• Jak wygląda samo hakowanie? Wszystko jest zautomatyzowane,  czy może robione ręcznie?

• Jak mogę zacząć hakować i znajdować podatności?

W końcu znalazłem się na HackerOne, platformie bug bounty stworzonej do łączenia hakerów etycznych z firmami, które szukają osób do przetestowania ich aplikacji. HackerOne pozwala hakerom i firmom upubliczniać błędy, które zostały znalezione i naprawione.

Czytając te ujawnione zgłoszenia, starałem się zrozumieć, w jaki sposób ludzie znajdują podatności oraz jak je wykorzystują. Często musiałem przeczytać to samo zgłoszenie dwa lub trzy razy, zanim je zrozumiałem. Tak samo jak pozostali początkujący, zdałem sobie sprawę z tego, że mógłbym wynieść o wiele więcej z objaśnień znalezionych podatności, gdyby były napisane prostym językiem.

Na tropie błędów. Przewodnik hakerski jest na to autorską odpowiedzią, która pomoże Ci zrozumieć wiele rodzajów podatności w aplikacjach internetowych. Nauczysz się szukać podatności, zgłaszać je, zarabiać na tym oraz, przy okazji, pisać bezpieczny kod. Książka ta nie omawia jedynie pomyślnych przykładów: znajdziesz w niej również błędy i wyciągnięte wnioski, z których wiele należy do mnie.

Do czasu, gdy skończysz czytanie, postawisz swój pierwszy krok w kierunku zwiększania bezpieczeństwa oraz powinieneś być w stanie zarabiać na tym pieniądze.

Dla kogo jest ta książka?

Ta książka została napisana z myślą o początkujących hakerach. Nie ma znaczenia, czy tworzysz strony internetowe, czy projektujesz je, czy jesteś rodzicem przebywającym w domu, 10-letnim dzieckiem, czy 75-letnim  emerytem.

Powiedziawszy to, choć nie jest to warunek konieczny do hakowania, pewne doświadczenie w programowaniu i znajomość z technologiami internetowymi mogą okazać się pomocne. Na przykład nie musisz być programistą internetowym, aby być hakerem, jednak znajomość podstawowego hipertekstowego języka znaczników (HTML), struktury strony internetowej, wyglądu kaskadowych arkuszy stylów (CSS) oraz tego, w jaki sposób JavaScript dynamicznie wchodzi w interakcję z witrynami, pomogą Ci odkrywać podatności i oceniać znaczenie znalezionych błędów.

Umiejętność programowania może pomóc, gdy szukasz podatności dotyczących logiki aplikacji oraz przy domysłach, gdzie programista mógł popełnić błędy. Jeśli potrafisz patrzeć z punktu widzenia programistów, zgadywać, w jaki sposób coś zostało zaimplementowane, bądź czytać ich kod (o ile jest dostępny), będziesz miał większą szansę na powodzenie.

Jeśli chcesz nauczyć się programowania, polecam Ci sprawdzić darmowe kursy na platformach Udacity oraz Coursera. Dodatkowe materiały znajdziesz w załączniku B.

Jak czytać tę książkę?

Każdy rozdział, który omawia określony rodzaj podatności, zbudowany jest w następujący sposób:

1. Opis rodzaju podatności.

2. Przykłady podatności.

3. Podsumowanie wraz z wnioskami.

Każdy przykład podatności zawiera następujące części:

1. Moją ocenę trudności w szukaniu i udowadnianiu tej podatności.

2. Adres URL powiązany z miejscem, w którym dana podatność została znaleziona.

3. Link do oryginalnego zgłoszenia bądź artykułu.

4. Data zgłoszenia podatności.

5. Kwota otrzymana za przesłanie informacji.

6. Przejrzysty opis podatności.

7. Wnioski, które warto zapamiętać.

Nie ma potrzeby czytania tej książki od deski do deski. Jeśli znajdziesz konkretny rozdział, którym jesteś zainteresowany, przeczytaj go najpierw. W niektórych przypadkach odnoszę się do pojęć omawianych w poprzednich rozdziałach, jednak robiąc to, staram się odnotować miejsce, w którym zdefiniowałem ten termin, dzięki czemu łatwiej Ci będzie znaleźć odpowiednią sekcję. Podczas hakowania trzymaj tę książkę otwartą.

Co znajdziesz w tej książce?

Oto przegląd tego, co znajdziesz w każdym z rozdziałów:

Rozdział 1: Podstawy Bug Bounty wyjaśnia, czym są podatności oraz programy bug bounty, oraz tłumaczy różnice między klientem a serwerem. Omawia również, w jaki sposób działa internet, a w tym żądania HTTP, odpowiedzi i metody, oraz co to znaczy, że HTTP jest bezstanowy.

Rozdział 2: Otwarte przekierowanie omawia ataki, które wykorzystują zaufanie użytkowników do określonej domeny w celu przekierowywania ich do innej.

Rozdział 3: HTTP Parameter Pollution omawia sposób, w jaki hakerzy manipulują żądaniami HTTP, wstrzykując dodatkowe parametry, którym dana witryna ufa, prowadząc w ten sposób do nieoczekiwanych rezultatów.

Rozdział 4: Cross-Site Request Forgery wyjaśnia sposób, w jaki atakujący może wykorzystać złośliwą stronę, aby przeglądarka ofiary wykonała żądanie HTTP do innej strony. Strona, która otrzymuje żądanie, postępuje tak, jakby żądanie zostało wysłane umyślnie przez ofiarę.

Rozdział 5: HTML Injection i fałszowanie treści tłumaczy, w jaki  sposób złośliwy użytkownik może wstrzykiwać własne elementy HTML na docelowe strony internetowe.

Rozdział 6: Carriage Return Line Feed Injection pokazuje, jak atakujący wstrzykują zakodowane znaki do wiadomości HTTP, aby zmienić to, w jaki sposób interpretują je serwery, proxy i przeglądarki.

Rozdział 7: Cross-Site Scripting wyjaśnia, w jaki sposób atakujący wykorzystują strony, które nie filtrują danych wejściowych użytkownika, w celu wykonywania na nich własnego kodu JavaScript.

Rozdział 8: Template Injection pokazuje, jak atakujący wykorzystują template engine’y w przypadku, gdy strona nie filtruje odpowiednio wejścia użytkownika i używa ich w swoich szablonach. Rozdział pokrywa zarówno przypadki po stronie klienta, jak i serwera.

Rozdział 9: SQL Injection opisuje, jak podatność po stronie aplikacji (serwera) może pozwolić atakującemu na zaatakowanie bazy danych.

Rozdział 10: Server-Side Request Forgery wyjaśnia, w jaki sposób  atakujący sprawiają, że serwer wykonuje niezamierzone żądania.

Rozdział 11: XML External Entity pokazuje, jak atakujący wykorzystują sposób, w jaki aplikacja parsuje dane wejściowe XML i przetwarza w nich zewnętrzne encje.

Rozdział 12: Zdalne wykonanie kodu dotyczy wykorzystywania serwera bądź aplikacji do uruchomienia na nich własnego kodu.

Rozdział 13: Podatności w manualnej obsłudze pamięci omawia sposoby, w jakie hakerzy wykorzystują zarządzanie pamięcią aplikacji do powodowania niezamierzonych działań, włączając w to możliwość wykonywania własnych poleceń.

Rozdział 14: Przejęcie subdomeny pokazuje, w jaki sposób atakujący może przejąć kontrolę nad subdomeną w imieniu uprawnionej domeny.

Rozdział 15: Race Condition wyjaśnia, jak atakujący wykorzystują sytuacje, w których zmiana warunku początkowego danego procesu ma wpływ na jego końcowy wynik.

Rozdział 16: Insecure Direct Object Reference omawia wszelkie podatności pojawiające się, gdy atakujący ma dostęp do odniesienia do obiektu, do którego nie powinien mieć dostępu, na przykład pliku, rekordu w bazie danych bądź konta.

Rozdział 17: Podatności OAuth pokazuje błędy w implementacji protokołu stworzonego do uproszczenia i ustandaryzowania bezpiecznego uwierzytelniania w aplikacjach internetowych, mobilnych i desktopowych.

Rozdział 18: Podatności w logice i konfiguracji aplikacji wyjaśnia, w jaki sposób atakujący mogą wykorzystać wadliwą logikę w kodzie lub błąd w konfiguracji do wykonania niezamierzonych działań.

Rozdział 19: Poszukiwanie podatności na własną rękę dostarcza wskazówki, gdzie i jak szukać podatności, bazując na moich doświadczeniach i metodologii. Ten rozdział nie jest jednak poradnikiem krok po kroku do włamywania się na stronę.

Rozdział 20: Zgłaszanie podatności omawia, w jaki sposób pisać wiarygodne i informacyjne zgłoszenia podatności, dzięki czemu programy nie odrzucą twoich raportów.

Załącznik A: Narzędzia omawia popularne narzędzia stworzone do hakowania, włączając w to przechwytywanie ruchu sieciowego, enumerację subdomen, wykonywanie zrzutów ekranu i wiele więcej.

Załącznik B: Źródła stanowi listę dodatkowych materiałów do dalszego rozwoju w dziedzinie hackingu. Znajdziesz tu między innymi ćwiczenia online, popularne platformy bug bounty i polecane blogi.

Zastrzeżenie dotyczące hakowania

Patrząc na upublicznione zgłoszenia podatności, a dokładniej na kwoty pieniędzy, które hakerzy za nie otrzymują, naturalnie może się wydawać, że hacking to łatwa i szybka droga do wzbogacenia się. Tak jednak nie jest. Poszukiwanie błędów potrafi być satysfakcjonujące, jednak mało prawdopodobne jest, że napotkasz wiele historii o porażkach, które zdarzają się po drodze (z wyjątkiem tej książki, gdzie dzielę się kilkoma naprawę kompromitującymi opowieściami). Ponieważ będziesz głównie słyszał o sukcesach hakerów, możesz rozwinąć nierealistyczne oczekiwania wobec swojej  hakerskiej przygody.

Sukces może przyjść do Ciebie bardzo szybko. Jednak jeśli masz problemy ze znajdowaniem błędów, nie przestawaj się zagłębiać. Programiści zawsze będą pisać nowy kod, a błędy stanowią nieuniknioną część tego procesu. Im bardziej się starasz, tym więcej błędów będziesz znajdował.

W tej sprawie możesz śmiało do mnie napisać na Twitterze @yaworsk i dać znać, jak sobie radzisz. Nawet jeśli nie odnosisz sukcesów, chciałbym to od Ciebie usłyszeć. Bug hunting potrafi być samotną pracą, szczególnie jeśli sprawia Ci trudności. Jednak wspaniale jest też wspólnie świętować, a może nawet znajdziesz coś, co będę mógł zamieścić w następnym wydaniu tej książki.

Powodzenia i szczęśliwego hakowania.

1.
PODSTAWY BUG BOUNTY

Jeżeli jesteś nowy w świecie hackingu, podstawowe zrozumienie tego, jak internet działa i co się dzieje „pod maską”, kiedy wpisujesz adres URL w przeglądarce, będzie Ci bardzo pomocne. Nawigacja po stronach internetowych może wydawać się prosta, lecz wbrew pozorom angażuje ona wiele ukrytych procesów, takich jak przygotowanie żądania HTTP, identyfikacja domeny, do której wysłać żądanie, tłumaczenie domeny na adres IP, przesłanie żądania, renderowanie odpowiedzi i tak dalej.

W tym rozdziale poznasz podstawowe koncepcje i terminologię, takie jak podatności, programy bug bounty, klient, serwer, adres IP oraz HTTP. Zrozumiesz, w jaki sposób wykonywanie niezamierzonych akcji i dostarczanie nieoczekiwanego wejścia lub dostępu do prywatnych informacji może skutkować podatnościami bezpieczeństwa. Następnie zobaczymy, co się dzieje, kiedy wpisujesz adres URL w pasku adresu swojej przeglądarki, włączając w to, jak wyglądają żądania i odpowiedzi HTTP, jak i również różne metody HTTP. Zakończymy rozdział ze zrozumieniem tego, co oznacza stwierdzenie, że protokół HTTP jest bezstanowy.

Podatności i Bug Bounty

Podatność jest to słabość aplikacji, która pozwala złośliwej osobie wykonać niedozwolone akcje lub uzyskać dostęp do informacji, których normalnie nie powinna być stanie uzyskać.

Podczas nauki i testowania aplikacji pamiętaj o tym, że podatności mogą skutkować działaniami zamierzonymi lub niezamierzonymi. Dla zobrazowania: zmiana parametru / pola ID identyfikatora rekordu w celu uzyskania informacji, do których nie powinieneś mieć dostępu, jest przykładem niezamierzonej akcji.

Załóżmy, że utworzyłeś profil ze swoją nazwą, e-mailem, datą urodzenia i adresem. Strona zachowałaby te informacje jako prywatne i umożliwiłaby do nich dostęp tylko Twoim znajomym. Jeśli jednak aplikacja internetowa pozwala komukolwiek dodawać Cię jako swojego znajomego bez Twojej zgody, byłaby to podatność bezpieczeństwa. Mimo że strona strzeże Twoich prywatnych danych przed nieznajomymi, pozwalając dowolnej osobie na dodanie Cię do swoich znajomych bez Twojej zgody, jednocześnie umożliwia ona każdemu dostęp do informacji o Tobie. Kiedy testujesz stronę internetową, zawsze rozważaj to, jak ktoś mógłby nadużyć obecnej  funkcjonalności.

Bug bounty to nagroda, którą strona lub firma przyznaje każdemu, kto w etyczny sposób znajdzie podatność i zgłosi ją do administracji bądź firmy. Nagrody są zazwyczaj pieniężne i wahają się od dziesiątek, aż po tysiące dolarów. Inne przykłady nagród to między innymi kryptowaluty, mile  lotnicze, punkty nagród bądź inne dobra cyfrowe.

Kiedy firma oferuje nagrody za znalezienie podatności, tworzy wyznaczony do tego program – termin, używany w tej książce, by oznaczyć zasady i strukturę ustanowione przez firmy dla ludzi, którzy chcą testować firmy  na te podatności. Zwróć uwagę na to, że różni się to od firm, które wykorzystują programy upubliczniania podatności (Vulnerability Disclosure Program – VDP). Programy bug bounty oferują nagrody pieniężne, podczas gdy VDP nie oferuje płatności (aczkolwiek firmy mogą nagradzać rzeczami). VDP to najzwyklejszy sposób dla uczciwych hakerów na zgłaszanie znalezionych podatności, aby dana firma mogła je naprawić. Mimo że nie wszystkie zgłoszenia przedstawione w tej książce zostały nagrodzone, wszystkie pochodzą od hakerów biorących udział w programach bug bounty.

Klient i serwer

Twoja przeglądarka korzysta z internetu, który jest siecią komputerów wysyłających do siebie wiadomości. Wiadomości te nazywamy pakietami. Pakiety zawierają dane, które wysyłasz, i informacje o tym, skąd te dane wychodzą i dokąd zmierzają. Każdy komputer w internecie ma adres do odbierania pakietów. Niektóre komputery akceptują tylko określone typy pakietów, a jeszcze inne akceptują pakiety tylko z ograniczonej listy innych komputerów. Kiedy komputer odbiera pakiet, zależy to tylko od niego, co z nim zrobi i jak odpowie. Na potrzeby tej książki skupimy się tylko na danych zawartych w pakietach (wiadomościach HTTP), a nie na samych  pakietach.

Będę się odwoływał do tych komputerów jako do klientów lub serwerów. Komputer inicjujący żądanie jest zazwyczaj nazywany klientem, niezależnie od tego, czy żądanie jest zainicjowane przez przeglądarkę, wiersz poleceń lub coś innego. Nazwa serwery odnosi się do stron i aplikacji internetowych odbierających żądania.

Ponieważ internet może mieć dowolną liczbę rozmawiających ze sobą komputerów, potrzebujemy wytycznych do tego, jak komputery powinny się komunikować przez internet. Przyjmują one formę dokumentów RFC (Request for Comment – prośba o komentarze), które definiują standardy tego, w jaki sposób komputery powinny się zachowywać. Na przykład protokół przesyłania dokumentów hipertekstowych – w skrócie HTTP (Hypertext Transfer Protocol) – określa, jak Twoja przeglądarka internetowa komunikuje się ze zdalnym serwerem przy użyciu protokołu internetowego IP (Internet Protocol). W tym przypadku zarówno klient, jak i serwer muszą się zgodzić na implementację tych samych standardów, dzięki czemu są w stanie zrozumieć  wysyłane i odbierane przez siebie pakiety.

Co się dzieje, kiedy odwiedzasz stronę

Ponieważ w tej książce skupiamy się na żądaniach HTTP, ta sekcja dostarczy Ci wysokopoziomowy wgląd na cały proces, który następuje po wpisaniu adresu URL w przeglądarce.

Krok 1: Identyfikacja domeny internetowej

Kiedy wpiszesz http://www.google.com/, Twoja przeglądarka ustala domenę z adresu URL. Domena identyfikuje stronę, którą próbujesz odwiedzić, i musi przy tym przestrzegać określonych zasad zdefiniowanych przez RFC. Na przykład domena może zawierać tylko znaki alfanumeryczne i podkreślenia. Jedyny wyjątek stanowią zinternacjonalizowane domeny, które wychodzą poza zakres tej książki. Jeśli chcesz dowiedzieć się więcej na ten temat, sprawdź dokument RFC 3490, który definiuje ich użycie. W tym przypadku domeną jest www.google.com. Domena służy jako jedna z dróg do znalezienia adresu serwera.

Krok 2: Ustalenie adresu IP

Po ustaleniu domeny, Twoja przeglądarka używa IP do sprawdzenia adresu IP powiązanego z tą stroną. Ten proces jest określany jako ustalanie adresu IP i każda domena w internecie musi zostać przetłumaczona na adres IP, aby działała.

Istnieją dwa rodzaje adresów IP, definiowane przez protokół internetowy w wersji 4 (IPv4) i w wersji 6 (IPv6). Adresy IPv4 są skonstruowane z czterech liczb połączonych kropkami, gdzie każdy numer jest z przedziału od 0 do 255. IPv6 jest najnowszą wersją protokołu internetowego. Został stworzony po to, by rozwiązać problem kończących się adresów IPv4. Adresy IPv6 są stworzone z ośmiu grup czterocyfrowych liczb dziesiętnych, oddzielonych dwukropkami, lecz istnieją metody na ich skrócenie. Na przykład 8.8.8.8 jest adresem IPv4, a 2001:4860:4860::8888 jest skróconym  adresem IPv6.

Aby znaleźć adres IP, używając domeny, Twój komputer wysyła żądanie do serwerów DNS (Domain Name System) składających się ze specjalnych serwerów w internecie, które mają rejestr wszystkich domen i odpowiadających im adresów IP. Powyższe adresy IPv4 i IPv6 są serwerami DNS Google.

W tym przypadku serwer DNS, do którego się łączysz, dopasowałby www.google.com do adresu IPv4 216.58.201.228 i wysłałby go z powrotem do Twojego komputera. By dowiedzieć się więcej na temat adresu IP konkretnej strony, możesz użyć komendy dig A site.com w swoim terminalu i zamienić site.com na stronę, którą chcesz sprawdzić.

Krok 3: Nawiązanie połączenia TCP

Następnie komputer próbuje nawiązać połączenie TCP (Transmission Control Protocol – protokół kontroli transmisji) z adresem IP przez port 80, ponieważ odwiedziłeś stronę, używając http://. Szczegóły na temat TCP nie są istotne oprócz tego, że jest to kolejny protokół, który definiuje sposób,  w jaki komputery komunikują się ze sobą. TCP zapewnia dwukierunkową komunikację, dzięki czemu odbiorcy wiadomości mogą zweryfikować  kompletność przesyłanej informacji podczas transmisji.

Serwer, do którego wysyłasz żądanie, może być w trakcie obsługi wielu usług (traktuj usługę jako program komputerowy), więc używa portów do identyfikacji konkretnych usług, aby odbierać żądania. Możesz je sobie wyobrazić jako drzwi serwera do internetu. Bez portów usługi musiałyby konkurować ze sobą o to, która informacja zostanie wysłana. Oznacza to, że potrzebujemy kolejnego standardu do zdefiniowania tego, jak usługi współpracują ze sobą i upewnić się, że dane dla jednej usługi nie są kradzione przez inne. Na przykład port 80 jest standardowym portem do wysyłania i odbierania żądań HTTP. Innym powszechnym portem jest 443, który jest używany do zaszyfrowanych żądań HTTPS. Mimo że port 80 jest standardem dla HTTP i 443 jest standardem dla HTTPS, komunikacja TCP może następować na dowolnym porcie, zależnie od konfiguracji aplikacji przez administratora.

Możesz nawiązać swoje własne połączenie TCP do strony internetowej przez port 80 przy użyciu terminala, wpisując komendę nc <ADRES IP> 80. Komenda nc używa narzędzia Netcat do utworzenia połączenia sieciowego do odczytywania i pisania wiadomości.

Krok 4: Wysyłanie zapytania HTTP

Kontynuując przykład ze stroną http://www.google.com/, jeśli połączenie w kroku 3 zostało nawiązane pomyślnie, Twoja przeglądarka powinna  przygotować i wysłać żądanie HTTP, tak jak w listingu 1.1:

GET / HTTP/1.1

Host: www.google.com

Connection: keep-alive

Accept: application/html, */*

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36

Listing 1.1. Wysyłanie żądania HTTP

Przeglądarka przygotowuje żądanie GET do ścieżki / one, która jest główną ścieżką dostępu strony. Zawartość strony jest organizowana ścieżkami, dokładnie tak samo jak foldery i pliki na Twoim komputerze. Gdy wchodzisz w kolejne foldery, ścieżka, którą podążasz, jest oznaczona przez zapisywanie nazw kolejnych folderów i dopisywanie / na ich końcu. Kiedy odwiedzasz pierwszą stronę na witrynie internetowej, dostajesz się do głównej ścieżki dostępu, którą jest po prostu /. Przeglądarka również sygnalizuje, że używa wersji 1.1 protokołu HTTP. Żądanie GET jedynie otrzymuje informacje. Dowiesz się o tym więcej później.

Nagłówek host two zawiera dodatkowe informacje, które są wysłane jako część zapytania. HTTP 1.1 potrzebuje ich, by określić, gdzie serwer dla danego adresu IP powinien przesłać żądanie, ponieważ adresy IP mogą hostować kilka domen na raz. Nagłówek connection three informuje, żeby utrzymać połączenie otwarte, aby uniknąć potrzeby ciągłego otwierania i zamykania połączeń.

Możesz zobaczyć oczekiwany format odpowiedzi w four. W tym przypadku oczekujemy application/html, lecz zaakceptujemy każdy format, co zostało oznaczone symbolem (*/*). Istnieją tysiące możliwych rodzajów zawartości, ale dla naszych potrzeb najczęściej będziesz wykorzystywał:  application/html, application/json, application/octet-stream oraz text/plain. W końcu User-Agent five określa oprogramowanie odpowiedzialne za wysyłanie żądań.

Krok 5: Odpowiedź serwera

W odpowiedzi na nasze żądanie serwer powinien odpowiedzieć czymś w rodzaju listingu 1.2:

HTTP/1.1 200 OK

Content-Type: text/html

<html>

  <head>

    <title>Google.com</title>

  </head>

  <body>

  three --cięcie--

  </body>

</html>

Listing 1.2. Odpowiedź serwera

Tutaj otrzymaliśmy odpowiedź HTTP z kodem statusu 200 one. Kod statusu jest istotny, ponieważ mówi o rezultacie odpowiedzi. Co również jest opisane przez RFC, kody te zazwyczaj mają trzycyfrowy numer, który zaczyna się 2, 3, 4 lub 5. Mimo że nie ma wyznaczonych standardów do używania konkretnych kodów, 2xx najczęściej oznacza sukces.

Ponieważ nie istnieje żaden wymóg co do tego, jak serwer implementuje użycie własnych kodów HTTP, możesz czasem zobaczyć odpowiedź z kodem 200, nawet jeśli dalsza odpowiedź HTTP opisuje błąd. Treść wiadomości HTTP jest tekstem powiązanym z żądaniem lub odpowiedzią three. W tym przypadku usunęliśmy zawartość i zamieniliśmy ją na –cięcie-- ze względu na wielkość treści wiadomości od Google. Zawartość odpowiedzi to zazwyczaj HTML dla strony internetowej, ale może być również tekstem JSON dla API, zawartością do pobrania i tak dalej.

Nagłówek Content-Type two informuje przeglądarkę o rodzaju treści. Rodzaj treści określa, w jaki sposób przeglądarka będzie renderować zawartość. Przeglądarki nie zawsze jednak używają wartości zwróconej przez aplikację; zamiast tego przeglądarka wykonuje tzw. MIME sniffing przez czytanie pierwszych bitów treści wiadomości, aby wykryć jej rodzaj samemu. Aplikacje mogą wyłączyć tę funkcję przez dołączanie nagłówka X-Content-Type-Options:nosniff, który w obecnym przykładzie nie został  dołączony.

Kolejny kod statusu, zaczynający się od 3 oznacza przekierowanie, co instruuje Twoją przeglądarkę do wykonania dodatkowego zapytania.  Na przykład, jeśli Google chciałby odesłać Cię na stałe z jednego adresu URL na drugi, użyłby odpowiedzi 301. Dla odróżnienia 302 oznacza  tymczasowe przekierowanie.

Gdy otrzymujesz odpowiedź 3xx, Twoja przeglądarka powinna wykonać nowe żądanie HTTP na adres URL wskazany w nagłówku Location:

HTTP/1.1 301 Found

Location: https://www.google.com/

Odpowiedzi zaczynające się od 4 najczęściej wskazują na błąd użytkownika, tak jak kod 403, kiedy żądanie nie będzie zawierało odpowiednich danych do wykonania uwierzytelnienia, mimo przesłania prawidłowego żądania HTTP. Odpowiedzi zaczynające się 5 oznaczają błąd po stronie serwera, przykładem może być kod 503, który oznacza, że serwer nie jest w stanie obsłużyć otrzymanego żądania.

Krok 6: Renderowanie odpowiedzi

Ponieważ serwer wysłał odpowiedź z kodem 200 i rodzajem text/html, nasza przeglądarka rozpocznie renderowanie wiadomości, którą otrzymała. Treść odpowiedzi mówi przeglądarce, co powinno zostać wyświetlone użytkownikowi.

Dla naszego przykładu byłby to HTML do budowy strony; kaskadowe arkusze stylów (CSS) do stylizacji i układu; JavaScript do dodatkowej funkcjonalności i mediów, takich jak zdjęć lub filmów. Serwer może również odpowiedzieć inną zawartością, taką jak XML, lecz dla tego przykładu zostaniemy przy podstawach. Rozdział 11 omawia XML w szczegółach.

W przypadku gdy strona internetowa ma zewnętrzną zawartość, taką jak CSS, JavaScript czy media, przeglądarka będzie musiała wykonać dodatkowe żądania HTTP dla wszystkich wymaganych plików przez daną witrynę. W trakcie gdy przeglądarka wysyła wymagane żądania, wciąż będzie analizować odpowiedź i wyświetlać zawartość jako stronę. W tym przypadku wyrenderuje główną stronę Google, www.google.com.

Zauważ, że JavaScript jest językiem skryptowym wspieranym przez każdą przeglądarkę. JavaScript pozwala stronom na posiadanie dynamicznej funkcjonalności, włączając w to możliwość aktualizacji elementów na stronie bez potrzeby odświeżania całej strony, sprawdzanie siły Twojego hasła (w przypadku niektórych stron) i wiele innych. Tak jak inne języki programowania, JavaScript ma wbudowane funkcje, może przechowywać wartości w zmiennych i potrafi uruchamiać kod w odpowiedzi na interakcje na stronie. Ma również dostęp do zróżnicowanych interfejsów programowania (API). Interfejsy te pozwalają językowi JavaScript na interakcję z innymi systemami, z czego jednym z najważniejszych jest obiektowy model dokumentu (DOM – Document Object Model).

DOM umożliwia językowi JavaScript dostęp i manipulację kodem HTML i CSS należącymi do strony. Jest to bardzo istotne, ponieważ jeśli intruz jest w stanie uruchomić własny kod JavaScript, będzie on mógł uzyskać dostęp do DOM-u i wykonać akcje na stronie w imieniu ofiary. Rozdział 7 rozwija to zagadnienie dokładniej.

Żądania HTTP

Zgoda między klientem a serwerem w użyciu wiadomości HTTP włącza definiowanie metod żądań. Metoda określa powód żądania przesyłanego przez klienta oraz to, czego oczekuje jako pozytywny rezultat. Dla zobrazowania w listingu 1.1 wysłaliśmy zapytanie GET do http://google.com/, implikując w ten sposób, że oczekujemy jedynie zawartości http://google.com/ w odpowiedzi, bez wykonywania dodatkowych akcji. Internet jest zaprojektowany jako interfejs między zdalnymi komputerami, z tego względu metody żądań zostały zbudowane i zaimplementowane po to, by rozpoznawać podejmowane akcje.

Standard HTTP definiuje następujące metody: GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT i OPTIONS (PATCH było również rozważane, lecz nie jest wystarczająco często implementowane). W momencie pisania tej książki, przeglądarki wysyłają jedynie żądania GET i POST przy użyciu HTML.  Jakiekolwiek żądanie PUT, PATCH lub DELETE może być wywołane jedynie przez JavaScript. Skupimy się na tym później, kiedy będziemy omawiać przykłady podatności aplikacji używających tych metod.

Następna część zawiera zwięzły przegląd rodzajów metod, które znajdziesz w tej książce.

Metody żądań

Metoda GET wyszukuje informacje zidentyfikowane przez URI żądania (Uniform Resource Identifier – ujednolicony identyfikator zasobów). Termin URI jest często synonimicznie używany z URL (Uniform Resource Locator – ujednolicony format adresowania zasobów). Technicznie rzecz biorąc, URL jest jednym z rodzajów URI, który określa zasoby, i zawiera sposób na odnalezienie ich przez lokalizację w sieci. Na przykład http://google.com/<example>/file.txt oraz <example>/file.txt są poprawnymi adresami URI. Jednak tylko http://google.com/<example>/file.txt jest poprawnym URL-em, ponieważ wskazuje, jak odnaleźć zasoby przez domenę http://www.google.com. Pomijając niuanse, kiedy będziemy w tej książce odnosić się do jakichkolwiek identyfikatorów, będziemy używać adresów URL.

Choć nie ma sposobu na wymuszenie tego warunku, żądania GET nie powinny modyfikować danych; powinny jedynie otrzymywać dane z serwera i zwracać je jako zawartość treści HTML. Dla zobrazowania na stronach mediów społecznościowych żądanie GET powinno jedynie zwracać nazwę Twojego profilu, nie aktualizować go. To zachowanie jest krytyczne w przypadku ataków CSRF (Cross-Site Request Forgery) omawianych w rozdziale 4. Odwiedzenie jakiegokolwiek linku bądź adresu URL (o ile nie zostało wykonane przez JavaScript) sprawia, że Twoja przeglądarka wysyła żądanie GET do zamierzonego serwera. Zachowanie to jest bardzo istotne w przypadku podatności na otwarte przekierowania, omawianych  w rozdziale 2.

Metoda HEAD jest identyczna z metodą GET z wyjątkiem tego, że serwer nie może przesłać treści wiadomości w odpowiedzi.

Metoda POST uruchamia niektóre funkcje ustalone przez połączony serwer. Innymi słowy, często na stronach podejmujesz pewnego rodzaju backendowe czynności, takie jak utworzenie komentarza, rejestracja użytkownika, usunięcie konta i tak dalej. Reakcja serwera na otrzymane od nas żądanie POST może być różna. Czasem serwer nie podejmie żadnej akcji, na przykład w przypadku, gdy wysłane żądanie POST spowodowało błąd podczas jego przetwarzania. W takiej sytuacji zmiany na serwerze  nie zostaną zapisane.

Metoda PUT wywołuje funkcje, które odnoszą się do istniejących już zapisów w zdalnej aplikacji bądź witrynie. Na przykład może być użyta podczas aktualizacji profilu, utworzenia posta na blogu bądź czymkolwiek,  co już istnieje. Ponownie podjęte akcje mogą być różne, a czasem nie zostanie  podjęta żadna.

Metoda DELETE wysyła żądanie dotyczące usunięcia zdalnego zasobu zidentyfikowanego przez URI.

Metoda TRACE jest kolejną rzadką metodą; jest używana do odesłania wysłanego żądania z powrotem do źródła. Pozwala wykonawcy żądania na zobaczenie tego, co jest odbierane przez serwer i użyć tej informacji do testów bądź zbierania danych diagnostycznych.

Metoda CONNECT jest zarezerwowana do użytku przez proxy, serwer pośredniczący między żądaniami. Ta metoda rozpoczyna dwukierunkową 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.