Читать книгу Na tropie błędów. Przewodnik hakerski - Peter Yaworski - Страница 10
1.
PODSTAWY BUG BOUNTY
Żą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.