Na tropie błędów. Przewodnik hakerski. Peter Yaworski
Читать онлайн книгу.
url_stats = 'https://eu1.badoo.com/chrome-push-stats?ws= 1&rt=<
Wartość url_stats przechowywała adres URL, który miał unikatową wartość rt w postaci parametru
<html>
<head>
<title>Badoo account take over</title>
</head>
<body>
<script>
return str.split('=')[2];
}
};
</script>
</body>
</html>
Kiedy ofiara załadowała tę witrynę, strona ładowała JavaScript pochodzący z Badoo, odwołując się do niego przez atrybut src w tagu <script>
Następnie Jamal utworzył zmienną csrf_code
https://eu1.badoo.com/chrome-push-stats?ws, 1&rt, <wartość_parametru_rt>
Następnie funkcja zwraca trzeci element tablicy, którym jest wartość rt i przypisuje ją do csrf_code.
Kiedy miał już token CSRF, Jamal stworzył zmienną csrf_url, która przechowuje adres URL do strony internetowej Badoo, /google/verify.phtml. Ta strona łączy jego własne konto Google z kontem Badoo ofiary
Wnioski
Nie ma dymu bez ognia. Jamal zauważył, że parametr rt był zwracany w różnych miejscach, a dokładniej w odpowiedziach JSON. Z tego też powodu prawidłowo zgadł, że wartość tego parametru może pojawić się w miejscu, do którego ma dostęp, w tym przypadku był to plik JavaScript. Jeśli odnosisz wrażenie, że strona może być podatna, to nie przestawaj szukać. W tym przypadku uznałem, że to dziwne, że parametr CSRF może mieć tylko 5 cyfr i być dołączony w adresach URL. Zazwyczaj tokeny są znacznie dłuższe, co czyni je trudniejszymi do odgadnięcia, oraz są dołączane w żądaniach HTTP, a nie w adresach URL. Używaj serwerów proxy i sprawdzaj wszystkie źródła, które są wywoływane, kiedy odwiedzasz daną stronę bądź aplikację. Burp Suite pozwala Ci przejrzeć całą historię proxy w celu poszukiwania konkretnych terminów lub wartości, które mogłyby ujawnić wartość rt zawartą w plikach JavaScript. Możesz w ten sposób znaleźć wyciek informacji z wrażliwymi danymi, takimi jak token CSRF.
Podsumowanie
Podatności CSRF stanowią kolejną możliwość ataku, który atakujący mogą wykonać bez żadnej wiedzy ofiary bądź potrzeby wykonania przez nią specjalnych czynności. Znalezienie CSRF-a wymaga sporo pomysłowości i wytrwałości, by w pełni przetestować aplikację.
Ogólnie rzecz biorąc, frameworki aplikacji, takie jak Ruby on Rails, coraz częściej chronią formularze w przypadku, gdy witryna wykonuje żą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