W poprzednim poście skupiłem głównie się na reflected CSS, ale wspomniałem również o stored XSS. Zasada działania ataków typu “Stored xss” jest bardzo prosta – wstrzyknięty kod jest przechowywany w bazie danych. Oznacza to, że potencjalny atak może zostać wykorzystany przeciwko jakiemukolwiek użytkownikowi odwiedzającemu stronę. W przypadku reflected xss sami musieliśmy zadbać o to, aby ktoś odwiedził stronę z spreparowanymi przez nas danymi.
Z tego względu stored xss (persistent xss) jest dużo bardziej niebezpieczny i większość współczesnych stron lub aplikacji internetowych posiada funkcjonalności, które potencjalnie mogą być podatne na XSS. Jeśli tylko aplikacja zawiera jakieś interaktywne elementy, np. służące do personalizacji strony lub wprowadzania nowej zawartości, wtedy warto zastanowić się czy autorzy przewidzieli, że dane pochodzące od użytkowników mogą zawierać złośliwy kod JavaScript.
Ten typ ataku często nazywany jest również “second-order xss”. Dlaczego? W celu poprawnego przeprowadzania ataku, możemy naszkicować dwa etapy:
- Atakujący wstrzykuje złośliwy kod JavaScript np. w formie komentarza na stronie internetowej. Wstrzyknięty kod może zawierać np. pokazany w poprzednim wpisie JS pobierający ciasteczka zawierające identyfikator sesji.
- Osoba odwiedzające stronę, otwiera komentarze, tym samym wykonuje kod odczytujący i wysyłający identyfikator sesji do serwera pod kontrolą osoby atakującej.
Po etapie drugim, identyfikator sesji zostaje skradziony. Skala takiego ataku jest ogromna – można przechwytywać sesje dowolnej osoby, która aktualnie odwiedza stronę. Co gorsze, osoba odwiedzające taką stronę jest kompletnie nieświadoma co się właśnie stało. W przypadku Reflected XSS, należy przekonać kogoś do odwiedzenia spreparowanego zapytania. Sam ten fakt, powinien być już podejrzany dla jakiekolwiek użytkownika. W przypadku Stored XSS, nie trzeba wykonywać nic podejrzanego – wystarczy wejść po prostu na zaatakowaną stronę, która niczym nie różni się (przynajmniej z wierzchu) od tej bez wstrzykniętego XSS.
Trzecim typem ataku jest tzw. ‘DOM-based XSS”. Różni się on od dwóch pierwszych tym, że wstrzyknięcie następuje po stronie klienta, a nie serwera. Podobny jest za to do Reflected XSS, ponieważ zwykle należy przekazać użytkownikowi spreparowany URL. Jak sama nazwa wskazuje, atak polega na odpowiednim (nieprzewidzianym przez autora) modyfikowaniu DOM. W klasycznym reflected XSS, to serwer modyfikuje odpowiedź i wspomniane wstrzyknięcie kodu również następuje poza przeglądarką użytkownika.
Klasyczny scenariusz DOM-based XSS to:
- Spreparowany link jest wysłany do ofiary
- Ofiara otwiera stronę. Odpowiedź generowana przez serwer nie zawiera nic podejrzanego.
- Przeglądarka modyfikuje DOM w sposób nieoczekiwany ponieważ jeden z parametrów w spreparowanym linku jest wstrzykiwany po stronie klienta.
Najlepiej zaprezentować to na przykładzie. Załóżmy, ze funkcjonalność wyświetlania błędów zaimplementowana w poprzednim poście, została przeniesiona do JS:
<script>
var url = document.location;
var errorMsg = url.substring(url.indexOf('error=') + 8, url.length);
document.write(errorMsg );
</script>
Jeśli ktoś przekaże jako parametr error, kod JS, a nie wiadomość, wtedy oczywiście efekt będzie taki sam jak w przypadku reflected xss. Łatwo sobie wyobrazić następujący URL:
www.domain.com\error?message=<script>alert('test')</script>
Chciałbym jeszcze zaprezentować przykład z OWASP. Załóżmy, że formularz wyboru języka na stronie wygląda następująco:
Select your language:
<select><script>
document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
document.write("<OPTION value=2>English</OPTION>");
</script></select>
Domyślny język jest przekazywany jest jako query parameter o nazwie “default”. Spodziewane wykorzystanie formularza to np.:
http://www.some.site/page.html?default=Polish
Łatwo jednak domyślić się, że ktoś może:
http://www.some.site/page.html?default=<script>alert(document.cookie)</script>
XSS jest dość znany i frameworki takie jak ASP.NET MVC, domyślnie potrafią np. kodować wyświetlane treści. Po stronie klienta sprawa wygląda zupełnie inaczej. Nie wszyscy korzystają z podobnych rozwiązań po stronie klienta (np. Angular). Bardzo często , szczególnie w skomplikowanych systemach, warstwa prezentacji w JS jest bardzo cienka i co za tym idzie, nie jest zbyt szczegółowo analizowana pod kątem bezpieczeństwa. Z tego względu, w praktyce łatwiej znaleźć strony podatne na “DOM-Based XSS” niż klasyczny “Reflected XSS”.
