Na tropie błędów. Przewodnik hakerski. Peter Yaworski
Читать онлайн книгу.
do pierwotnej wersji strony. Wpisane przez niego informacje zostają jednak przesłane do atakującego.
Na przykład, jeśli strona wyświetla zawartość, którą możesz kontrolować, być może jesteś w stanie dodać znacznik <form> do witryny, prosząc użytkownika, by podał ponownie swój login i hasło, tak jak tutaj:
<input type='text' name='username' value=''>
<input type='password' name='password' value=''>
<input type='submit' value='submit'>
</form>
Kiedy użytkownik prześle ten formularz, informacja zostanie wysłana na stronę atakującego http://<attacker>.com/capture.php przez atrybut action
Content spoofing jest bardzo podobny do HTML injection, z tą różnicą, że atakujący może wstrzyknąć tylko czysty tekst, bez tagów HTML. Takie ograniczenie najczęściej wynika z tego, że witryna opuszcza jakikolwiek kod HTML bądź usuwa tagi HTML przesłane w odpowiedziach HTTP. Mimo że atakujący nie są w stanie formatować strony internetowej przez content spoofing, mają możliwość umieścić na niej wiadomość, która wygląda na prawdziwą. Takie wiadomości mogą nakłonić użytkowników do podjęcia pewnych interakcji, lecz opierają się mocno na inżynierii społecznej. Kolejne przykłady zademonstrują, jak można odkrywać te luki.
Wstrzyknięcie formularza na stronie Coinbase
Poziom trudności: Niski
URL: https://coinbase.com/apps/
Źródło: https://hackerone.com/reports/104543/
Data zgłoszenia: 10 grudnia 2015
Nagroda: 200 $
Niektóre strony używają filtrów w celu pozbycia się tagów HTML, chroniąc stronę przed atakami HTML injection; czasami jednak jesteś w stanie obejść to zabezpieczenie za pomocą encji HTML. W przypadku tej podatności autor zgłoszenia zauważył, że Coinbase dekodował encje HTML podczas wyświetlania tekstu w recenzjach użytkowników. W HTML-u niektóre znaki są zarezerwowane, ponieważ pełnią konkretną funkcję (tak jak nawiasy kątowe < >, które otwierają i zamykają tagi HTML). Zarezerwowane znaki powinny być renderowane przy użyciu ich encji HTML; na przykład znak > powinien być renderowany przez strony jako >, by uniknąć podatności typu injection. Jednakże nawet zwykły znak może zostać wyrenderowany jako zakodowany w HTML-u; na przykład encją litery a jest a.
W przypadku tego błędu, autor zgłaszenia najpierw wprowadził zwykły tekst HTML w pole tekstowe przygotowane do recenzji użytkowników:
<h1>This is a test</h1>
Filtr w serwisie Coinbase pozbywa się języka HTML i wyświetli powyższą wiadomość jako zwykły tekst. Będzie on dokładnie taki sam, z wyjątkiem usuniętych tagów HTML. Co innego jednak, jeśli użytkownik przesłał od razu zakodowaną w HTML-u wiadomość, tak jak tutaj:
<h1>This is a test</h1>
W przypadku takiej wiadomości Coinbase pozostawił tagi, a następnie dekodował cały tekst na HTML, co skutkowało poprawnym renderowaniem tagów <h1> w przesłanej wiadomości:
Używając zakodowanych w HTML-u wartości, autor zgłoszenia zademonstrował, jak mógł wyświetlić pole do wpisania nazwy użytkownika i hasła:
Username:<br><input type="text" name="firstname"><br>Password:<br><input type="password" name="lastname">
Powyższy tekst przetłumaczony do HTML-a wygląda następująco:
Username:<br>
<input type="text" name="firstname">
<br>
Password:<br>
<input type="password" name="lastname">
Renderuje on pola wejściowe dla tekstu, które wyglądają jak miejsce do wprowadzenia nazwy użytkownika i hasła. Złośliwy haker mógł użyć tej podatności w celu wyłudzenia od użytkowników ich danych do logowania, które następnie zostałyby przesłane na stronę przechwytującą. Ta podatność zależy jednak od tego, czy użytkownik da się oszukać, wierząc, że formularz jest prawdziwy. W konsekwencji Coinbase nagrodził hakera niższą wypłatą w porównaniu z podatnościami, które nie wymagają interakcji ze strony użytkownika.
Wnioski
Kiedy testujesz witrynę, sprawdź, w jaki sposób traktuje ona różne źródła wejścia, włączając w to zwykły i zakodowany tekst. Miej na uwadze strony, które przyjmują wartości kodowane w URI, takie jak %2F, a następnie renderują ich dekodowane odpowiedniki, co w tym przypadku dałoby nam /.
Pod adresem https://gchq.github.io/CyberChef/ znajdziesz bardzo praktyczną aplikację, która zawiera zbiór narzędzi do kodowania. Warto ją sprawdzić.
Dodanie kodu HTML w serwisie HackerOne
Poziom trudności: Średni
URL: https://hackerone.com/reports/
Źródło: https://hackerone.com/reports/110578/
Data zgłoszenia: 13 stycznia 2016
Nagroda: 500 $
Następny przykład wymaga znajomości języka Markdown, Reacta i obiektowego modelu dokumentu (DOM), dlatego najpierw omówię te tematy, a następnie wytłumaczę, w jaki sposób doprowadziły one do powstania dwóch powiązanych ze sobą błędów.
Markdown to rodzaj języka znaczników, który używa specyficznej składni do generowania kodu HTML. Na przykład Markdown przetłumaczy zwykły tekst poprzedzony symbolem kratki (#) i zwróci HTML sformatowany w znacznikach nagłówka. Oznaczenie # Some Content zwróci <h1>Some Content</h1>. Deweloperzy często używają języka Markdown w edytorach stron internetowych, ponieważ jest on łatwy w użyciu. W dodatku na stronach, które pozwalają użytkownikom wprowadzać tekst, deweloperzy nie muszą się martwić formatowaniem HTML-a, ponieważ edytor robi to za nich.
Błędy które omówimy w tym przykładzie, korzystały ze składni Markdowna do wygenerowania tagu <a> (zwanego też kotwicą) z atrybutrem title. Domyślnie składnia służąca do tego wygląda tak:
[test](https://torontowebsitedeveloper.com "Your title tag here")
Tekst, który ma się wyświetlać, znajduje się w kwadratowym nawiasie, a adres URL, do którego przekierowuje link, jest umieszczony między okrągłymi nawiasami razem z atrybutem title umieszczonym w cudzysłowie. Taka składnia generuje następujący kod HTML:
<a href="https://torontowebsitedeveloper.com" title="Your title tag here">test</a>
W styczniu 2016 roku bug hunter Inti De Ceukelaire zauważył, że edytor Markdown w serwisie HackerOne został źle skonfigurowany; w wyniku tego atakujący mógł dodać pojedynczy cudzysłów do składni Markdowna, który następnie był umieszczany w wygenerowanym