Читать книгу Na tropie błędów. Przewodnik hakerski - Peter Yaworski - Страница 23

Poziom trudności: Niski

URL: https://www.twitter.com/

Źródło: https://ericrafaloff.com/parameter-tampering-attack-on-twitter-webintents/

Data zgłoszenia: Listopad 2015

Nagroda: Nieujawniona

W niektórych przypadkach podatność HPP może sygnalizować inne problemy i doprowadzić do znalezienia dodatkowych błędów. Tak właśnie się stało z funkcją Twittera – Web Intents. Dostarcza ona okna pop-up do interakcji z tweetami użytkownika, odpowiedziami, retweetami, polubieniami i pozwala robić to z poziomu innych stron niż Twitter. Web Intent uwalnia użytkowników od potrzeby uwierzytelniania nowej aplikacji w celach interakcji na Twitterze. Rysunek 3.1 pokazuje, jak jedno z tych okien wygląda.

Rysunek 3.1. Wczesna wersja funkcjonalności Web Intents, która pozwala  użytkownikom na interakcję z zawartością Twittera bez opuszczania strony.  W tym przykładzie użytkownicy mogą polubić tweeta Jacka

Testując tą funkcję, haker Eric Rafaloff odkrył, że wszystkie cztery rodzaje interakcji – obserwowanie użytkownika, polubienie tweeta, retweetowanie i tweetowanie – były podatne na HPP. Twitter przygotowywał okna za pomocą żądania GET z parametrami URL, takimi jak w przykładzie:

https://twitter.com/intent/intentType?parameter_name=parameterValue

Ten adres zawierał intentType i jedną lub więcej dodatkowych par parametrów i ich wartości – na przykład nazwę użytkownika i ID Tweeta. Twitter używał tych parametrów do utworzenia okna pop-up z możliwością polubienia tweeta bądź obserwowania użytkownika. 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:

<form class="follow" id="follow_btn_form" action="/intent/ follow?screen_name=ericrtest3" method="post">

<input type="hidden" name="authenticity_token" value="…">

<input type="hidden" name="screen_name" value="twitter">

<input type="hidden" name="profile_id" value="783214">

<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  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.