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

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

СКАЧАТЬ style="font-size:15px;">      end

      Ten kod tworzy dwie funkcje, prepare_transfer i transfer_money. Funkcja prepare_transfer używa tablicy o nazwie params

, która zawiera parametry to i amount pochodzące z URL-a. Tablicę stanowiłoby [67890,5000], gdzie jej wartości są wciśnięte między nawiasy, a każda wartość jest oddzielona przecinkiem. Pierwsza linia funkcji dodaje informacje o koncie użytkownika, które zostały zdefiniowane wcześniej w kodzie, na końcu tablicy. Dostajemy zatem tablicę params [67890,5000,12345], która następnie jest przekazana do transfer_money . Zauważ to, że w odróżnieniu od parametrów tablice nie mają nazw powiązanych z ich wartościami, więc kod podlega tablicy zawierającej zawsze każdą wartość w następującej kolejności: konto odbiorcy jako pierwsze, kwota przelewu druga i konto, z którego wychodzi przelew, jako następne. W transfer_money kolejność wartości staje się oczywista z racji, że funkcja przypisuje każdą wartość tablicy do zmiennej. Ze względu na to, że tablice są numerowane od 0, params[0] przyjmuje pierwszą wartość w tablicy, którą w tym przypadku jest 67890 i przypisuje ją do zmiennej to . Pozostałe wartości są również przypisywane zmiennym w wierszach i . Wtedy nazwy zmiennych są przekazane do funkcji transfer, niepokazanej w tym fragmencie, która przyjmuje wartości i wykonuje przelew.

      W najlepszej sytuacji parametry URL byłyby zawsze formatowane w sposób, jakiego kod oczekuje. Jednakże atakujący mógłby zmienić wynik tego procesu przez podanie w from wartości dla params, tak jak z następującym URL-em:

      https://www.bank.com/transfer?to=67890&amount=5000&from=ABCDEF

      W tej sytuacji parametr from jest również włączony do tablicy params przekazanej funkcji prepare_transfer; co za tym idzie, wartościami tablicy mogłyby być [67890,5000,ABCDEF], a podanie konta użytkownika w 

dawałoby rezultat w postaci [67890,5000,ABCDEF,12345]. W wyniku tego w funkcji transfer_money wywołanej w prepare_tranfer wartość from stałaby się trzecim parametrem, zamieniając oczekiwaną wartość 12345 na wartość atakującego ABCDEF .

      HPP po stronie klienta

      Podatności HPP po stronie klienta pozwalają atakującym na wstrzyknięcie dodatkowych parametrów do adresu URL, w celu wywołania efektów po stronie użytkownika (strona klienta jest częstym sposobem odnoszenia się do akcji, które dzieją się na twoim komputerze, często przez przeglądarkę, a nie po stronie serwera).

      Luca Carettoni i Stefano di Paola w swojej prezentacji zamieścili przykład tego zachowania, używając wymyślonego adresu URL http://host/page.php?par=123%26action=edit i następującego kodu na serwerze:

      

<? $val=htmlspecialchars($_GET['par'],ENT_QUOTES); ?>

      

<a href="/page.php?action=view&par='.<?=$val?>.'">View Me!</a>

      Ten kod generuje nowy adres URL, bazując na wartości par parametru wpisanego przez użytkownika. W tym przykładzie atakujący przekazuje wartość 123%26action=edit jako wartość dla par w celu wygenerowania dodatkowego, nieoczekiwanego parametru. Wartością dla & zakodowaną przez URL jest %26, co oznacza, że kiedy URL jest przetwarzany, %26 jest interpretowane jako &. Ta wartość dodaje dodatkowy parametr do wygenerowanego href-a, bez sprecyzowania parametru w URL-u. Używając parametru 123&action=edit zamiast %26, & byłoby zinterpretowane jako oddzielenie dwóch parametrów, lecz ze względu na to, że strona używa tylko jednego parametru par w swoim kodzie, parametr action zostałby usunięty. Wartość %26 omija ten problem, zapewniając, że akcja nie jest rozpoznawana jako osobny parametr, a więc 123%26action=edit staje się wartością par.

      Następnie par (z zakodowanym & jako %26) jest przekazany do funkcji htmlspecialchars

. Funkcja htmlspecialchars konwertuje znaki specjalne, takie jak %26, do ich zakodowanych w HTML-u wartości, zamieniając %26 na &amp; (jednostka w HTML-u, która reprezentuje &), gdzie ten znak może mieć specjalne znaczenie. Zmieniona wartość jest następnie przechowywana w $val. W następnej kolejności generowany jest nowy link przez dodanie $val do wartości href w . Zatem wygenerowany link to <a href="/page.php?action=view&par=123&action=edit">. W konsekwencji atakujący zdołał dodać nieoczekiwany action=edit do URL-a href, który mógłby doprowadzić do podatności w zależności od tego, jak aplikacja traktuje przemycony parametr action.

      Następne 3 przykłady wyjaśniają szczegółowo oba błędy HPP, zarówno po stronie serwera, jak i klienta, znalezione na HackerOne i Twitterze. Wszystkie z tych przykładów wymagają manipulowania parametrami URL. Miej na uwadze fakt, że żaden z przykładów nie używa tej samej metody lub nie współdzieli głównej przyczyny istnienia błędu, podkreślając istotę dokładnego testowania w poszukiwaniach podatności HPP.

      Przyciski do udostępniania na HackerOne

      Poziom trudności: Niski

      URL: https://hackerone.com/blog/introducing-signal-and-impact/

      Ź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:

      https://www.facebook.com/sharer.php?u=https://hackerone.com/blog/introducing-signal?&u=https://vk.com/durov

      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 СКАЧАТЬ