Źródło: https://hackerone.com/reports/105953/

      Data zgłoszenia: 18 grudnia 2015

      Nagroda: 500 $

      Jedną z metod na znajdowanie podatności HPP jest szukanie linków, które łączą się z zewnętrznymi serwisami. Blog na HackerOne robi to, dodając linki do udostępniania zawartości w popularnych serwisach społecznościowych, takich jak Twitter lub Facebook. Po kliknięciu linki te generują gotową treść dla użytkownika do publikacji na swoim profilu. Opublikowana treść zawiera odnośnik URL do oryginalnego posta.

      Pewien haker odkrył podatność, która pozwoliła mu na dołączenie parametru do adresu URL z postem na blogu HackerOne. Dodany parametr był umieszczany w udostępnionym linku, przez co treść mogła odsyłać  w inne miejsce niż zamierzony post na blogu.

      Przykład użyty w tym zgłoszeniu podatności korzystał z URL-a https://hackerone.com/blog/introducing-signal, a następnie na jego końcu wystarczyło dodać &u=https://vk.com/durov. Na stronie bloga, kiedy HackerOne renderował link do udostępnienia na Facebooku, link prezentował się następująco:

      Jeśli użytkownicy HackerOne kliknęli zainfekowany link, chcąc udostępnić post, ostatni parametr u miał pierwszeństwo nad pierwszym. Co za tym idzie, post na Facebooku użyłby ostatniego parametru u. Wtedy użytkownicy Facebooka, którzy kliknęli w link, zostaliby odesłani na https://vk.com/durov zamiast na HackerOne.

      Co więcej, w przypadku postów na Twitterze, HackerOne dołącza domyślny tekst do tweeta, który promuje post. Atakujący mógł również manipulować tym tekstem, dołączając do adresu &text=, tak jak tutaj:

      Kiedy użytkownik kliknął w poprzedzający link, wyświetliło się przed nim okno pop-up z tweetem zawierającym tekst “another_site: https://vk.com/durov”, zamiast tekstu promującego blog HackerOne.

      Wnioski

      Wypatruj podatności w sytuacjach, gdy strona akceptuje zawartość, łączy się z innym serwisem (takim jak media społecznościowe) i bazuje na obecnym adresie URL w celu wygenerowania zawartości do publikacji.

      W takich przypadkach możliwe jest, że przesyłana zawartość nie podlega żadnym kontrolom bezpieczeństwa, co może prowadzić do podatności HPP.

      Anulowanie subskrypcji powiadomień na Twitterze

      W niektórych przypadkach szukanie podatności HPP z powodzeniem wymaga niemałej wytrwałości. W sierpniu 2015 roku haker Mert Tasci, podczas anulowania subskrypcji powiadomień z Twittera, zauważył interesujący URL (który na potrzeby książki został skrócony):

      Zwróć uwagę na parametr UID. Okazuje się, że jest on numerem ID użytkownika, który jest obecnie zalogowany. Po dostrzeżeniu UID Tasci zrobił to, co na jego miejscu zrobiłaby większość hakerów – spróbował zmienić obecny UID na inny, należący do innego użytkownika, jednak nic się nie stało. Twitter zwrócił błąd.

      Podczas gdy inni w tym miejscu poddaliby się, zdeterminowany Tasci kontynuował; spróbował on dodać drugi parametr UID w taki sposób, że adres URL wyglądał następująco (ponownie, skrócona wersja):

      Sukces! Udało mu się anulować subskrypcję powiadomień e-mail u innego użytkownika. Twitter był podatny na HPP anulowania subskrypcji użytkowników. Powód, dla którego warto zapamiętać tą podatność, wyjaśnił mi FileDescriptor. Chodzi o parametr SIG. Jak się okazuje, Twitter generuje wartość SIG na podstawie wartości UID. Kiedy użytkownik klika w link do anulowania subskrypcji, Twitter weryfikuje, czy link nie został zmodyfikowany, sprawdzając wartości SIG i UID. W przypadku pierwszej próby Tasciego zmiana UID w celu anulowania subskrypcji u innego użytkownika zawiodła, ponieważ podpis nie pasował do tego, którego Twitter oczekiwał. Jednakże, dodając drugi UID, Tasciemu udało się oszukać Twittera, który sprawdzał podpis, używając pierwszego parametru UID, a wykonywał  właściwą akcję przy użyciu tego drugiego.

      Wnioski

      Wysiłek Tasciego pokazuje, jak ważna jest wytrwałość i wiedza. Jeżeli odpuściłby po początkowej próbie zmiany UID na inną wartość lub nie wiedziałby o podatnościach typu HPP, nie otrzymałby nagrody 700 $.

      Ty również miej na oku parametry z liczbami, które są automatycznie zwiększane, takimi jak UID, które znajdują się w żądaniach HTTP: wiele podatności wymaga manipulowania wartościami parametrów takimi jak te, aby spowodować w aplikacji nieoczekiwane zachowania. Przedyskutujemy ten temat dokładnie w rozdziale 16.

      Web Intents Twittera

      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

---

Скачать книгу