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

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

СКАЧАТЬ style="font-size:15px;">      </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 

i  został użyty pierwszy parametr screen_name. Jednakże po kliknięciu przycisku ofiara zaobserwowałaby konto ericrtest3, ponieważ atrybut action w tagu formularza używał drugiej wartości screen_name przekazanej  do URL-a.

      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 przykład parą nazwa/wartość w pliku cookie może być session Id=9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d 6c15b0f00a08, a plik może mieć atrybut domain o wartości .site.com. Co za tym idzie, plik sessionId będzie wysyłany do każdej witryny .<site>.com, którą użytkownik odwiedzi, na przykład: foo.<site>.com, bar.<site>.com, www .<site>.com i tak dalej.

      Atrybuty secure i httponly mówią przeglądarce, kiedy i jak wysyłać oraz czytać pliki cookies. Te atrybuty nie mają wartości; zamiast tego działają jako flagi, które albo są obecne w pliku, albo nie. Kiedy cookie ma atrybut secure, przeglądarka wyśle ten plik tylko przy połączeniu HTTPS. Na przykład, jeśli odwiedziłeś http://www.<site>.com/ (stronę HTTP) z bezpiecznym plikiem cookie, przeglądarka nie wyśle tego pliku na tę stronę. Powodem jest konieczność ochrony twoich danych, gdyż połączenia СКАЧАТЬ