Na tropie błędów. Przewodnik hakerski. Peter Yaworski
Читать онлайн книгу.
Rafaloff odkrył problem, kiedy utworzył URL z dwoma parametrami screen_name zamiast domyślnie jednego, tak jak tutaj:
https://twitter.com/intent/follow?screen_name=twitter&screen_name=ericrtest3
Podczas generowania przycisku Follow, Twitter wykonałby żądanie, korzystając z drugiej wartości parametru screen_name – ericrtest3 – zamiast pierwszej. Co za tym idzie, użytkownik próbujący zaobserwować oficjalny profil Twittera tak naprawdę obserwował testowe konto Rafaloffa. Odwiedzając URL, który przygotował Rafaloff, kod na serwerze Twittera generował poniższy formularz HTML, używając obu parametrów screen_name:
<input type="hidden" name="authenticity_token" value="…">
<button class="button" type="submit">
<b></b><strong>Follow</strong>
</button>
</form>
Twitter używał informacji z pierwszego parametru screen_name, która dotyczy oficjalnego konta Twittera. W rezultacie użytkownik widział poprawny profil użytkownika, który zamierzał zaobserwować, ponieważ w
W przypadku pozostałych interakcji, takich jak polubienie, Rafaloff zauważył, że wciąż może dodać parametr screen_name z podobnymi skutkami. Rozważmy jako przykład taki URL:
https://twitter.com/intent/like?tweet_i.d=6616252302978211845 &screen _name=ericrtest3
Domyślnie okno potrzebowałoby tylko parametru twitter_id; Rafaloff jednakże umieścił na końcu URL-a parametr screen_name. Próbując polubić tego tweeta, ofiara zobaczyłaby prawidłowy profil użytkownika, lecz znajdujący się obok przycisk Follow dotyczyłby niezwiązanego z postem użytkownika – ericrtest3.
Wnioski
Podatność w funkcji Web Intents Twittera jest podobna do poprzedniej podatności dotyczącej UID. Nic dziwnego zatem, że jeśli strona ma wady, takie jak HPP, to może być to oznaką istnienia szerszego problemu w systemie. Czasami, kiedy znajdziesz podobną podatność, warto jest poświęcić czas na zbadanie całej platformy, by spróbować wykorzystać wadę w miejscach opartych na podobnych mechanizmach.
Podsumowanie
Ryzyko stwarzane przez HPP jest zależne od akcji, które podejmuje backend aplikacji oraz od zainfekowanych parametrów, które zostały użyte.
Odnalezienie podatności HPP wymaga bardziej dokładnego testowania niż w przypadku pozostałych podatności z tego względu, że nie mamy dostępu do kodu, na którym serwer operuje po otrzymaniu żądania HTTP. Oznacza to, że możemy tylko domyślać się, jak serwer używa parametrów, które od nas otrzymał.
Metodą prób i błędów jesteś w stanie odkryć, w jakich sytuacjach pojawiają się podatności HPP. Często linki do mediów społecznościowych są dobrym miejscem do rozpoczęcia testów, pamiętaj jednak, by nie przestawać próbować i myśleć o HPP podczas testowania parametrów takich jak ID.
4.
CROSS-SITE REQUEST FORGERY
Atak Cross-Site Request Forgery (CSRF) polega na zmuszeniu przeglądarki ofiary do wysłania żądania HTTP na inną stronę internetową. Ta strona następnie podejmuje akcje w imieniu ofiary, robiąc to jednocześnie bez jej wiedzy. Tego typu ataki są możliwe, jeśli ofiara była poprzednio zautoryzowana na podatnej stronie. Pomyślny atak CSRF
może doprowadzić do modyfikacji informacji po stronie serwera, a nawet całkowitego przejęcia konta. Oto uproszczony przykład, który pokrótce omówimy:
1. Bob loguje się do swojego banku internetowego w celu sprawdzenia stanu konta.
2. Kiedy skończył, Bob sprawdza swój e-mail na innej domenie.
3. Bob otrzymał wiadomość z linkiem, który prowadzi na nieznaną stronę. Bob z ciekawości postanawia w niego kliknąć.
4. Strona, którą odwiedził, wysyła żądanie HTTP na stronę bankową Boba, w celu wykonania przelewu pieniędzy na konto atakującego.
5. Strona bankowa otrzymuje żądanie HTTP zainicjowane przez nieznaną stronę. Ponieważ bank nie ma odpowiednich zabezpieczeń CSRF, przetwarza przelew.
Uwierzytelnianie
Ataki CSRF wykorzystują słabości w procesie uwierzytelniania żądań aplikacji internetowych. Gdy odwiedzasz stronę, która wymaga logowania, najczęściej za pomocą loginu i hasła, dokonuje ona uwierzytelnienia, dzięki czemu nie będziesz musiał się logować za każdym razem, kiedy odwiedzisz nową stronę w obrębie tej samej domeny. Uwierzytelnienie można przechować na dwa sposoby: przy użyciu podstawowego protokołu uwierzytelniania lub plików cookies.
By rozpoznać stronę, która używa mechanizmu podstawowego uwierzytelniania HTTP, wystarczy sprawdzić, czy żądanie HTTP zawiera nagłówek, który wygląda jak ten: Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l. To, co wygląda na przypadkową serię znaków, jest zakodowanym w base64 loginem i hasłem, oddzielonymi dwukropkiem. W tym przypadku QWxhZGR pbjpPcGVuU2VzYW1l koduje Alladin:OpenSesame. W tym rozdziale nie będziemy się skupiać na podstawowym uwierzytelnianiu, lecz mimo wszystko możesz użyć wielu z przedstawionych tu technik, by wykorzystać podatności CSRF, które korzystają z podstawowego uwierzytelniania.
Cookies są małymi plikami, które strony internetowe tworzą i przechowują w przeglądarce użytkownika. Witryny używają cookies w różnych celach, takich jak przechowywanie informacji o preferencjach użytkownika czy historii odwiedzin danej strony. Cookies mają swoje atrybuty, które są znormalizowanymi informacjami. Takie detale mówią przeglądarce więcej o samych plikach oraz o tym, jak je traktować. Niektórymi z tych atrybutów są domain, expires, max-age, secure i httponly, o których dowiesz się więcej w tym rozdziale. Oprócz atrybutów cookies zawierają pary nazwa/wartość, które składają się z identyfikatora i powiązanej z nim wartości przekazywanej do strony (atrybut domain określa witrynę, do której należy przekazać te informacje).
Przeglądarki ustalają liczbę plików cookies, które strona może ustawić. Zazwyczaj jednak pojedyncza strona może ustawić od 50 do 150 plików w większości popularnych przeglądarek, choć niektóre z nich deklarują obsługę aż do 600. Przeglądarki pozwalają witrynom używać maksymalnie 4 kB na jeden plik cookie. Nie ma żadnego standardu w nazewnictwie bądź wartościach cookies: strony mają pełną dowolność w wyborze własnych par nazwa/wartość i ich przeznaczenia. Na przykład witryna może używać pliku o nazwie sessionId w celu zapamiętania, kim jest użytkownik, aniżeli wymagać od niego wpisania loginu i hasła przy każdej interakcji. (Pamiętaj, że żądania HTTP są bezstanowe, co opisaliśmy w rozdziale 1. Bezstanowy oznacza, że za każdym żądaniem HTTP witryna nie ma pojęcia, kim jest użytkownik, więc musi go ponownie uwierzytelnić dla każdego żądania.)
Na