Wprowadzenie do XSS

W ponizszym artykule skupimy się na rodzajach i typach XSS. Na początku musimy sobie odpowiedzieć pytanie, czym on jest. Na stronie OWASP, możemy przeczytać:

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites.
https://owasp.org/www-community/attacks/xss/

Jak możemy wyczytać z powyższej definicji, XSS jest umieszczeniem złośliwego kodu, którego użytkownik nie spodziewa się na stronie. Do typów ataków, zalicza się: Stored XSS (znany też jako Persistent lub Typu 1), Reflected XSS (znany też jako Non-Persistent lub Typu 2) oraz DOM Based XSS (znany też jako Typu 0). Z kolei rodzaje XSS dzielimy na te, po stronie serwera (Server XSS) oraz klienta (Client XSS).

Stored XSS (Persistent or Type 1)

Złośliwy kod znajduje się po stronie serwera. Z tego powodu jest to najbardziej niebezpieczny z typów XSS. Atak może zostać więc wykorzystany przeciwko każdemu, kto odwiedzi stronę. Poniższy przykład dokładnie to ilustruje.

Przykładowo, zakładamy, że użytkownik ma możliwość wstawiania postów, które generowane są dla innych użytkowników w tagach <p>. Taki sposobem, użytkownik wrzuca jako swój post skrypt, który generowany jest w poniższy sposób:

<script>alert(1);</script>

Za każdym razem, kiedy ktoś sprawdzi post użytkownika, wyświetli mu się alert.

Reflected XSS (Non-Persistent or Type 2)

Najprościej mówiąc, jest to umieszczenie kodu javascript w linku. Aby atak się powiódł, użytkownik musi kliknąć w przygotowany przez atakującego URI.

Przykładowo, po wejściu na stronę https://dummy-domain.com/website32325/, oczom naszym ukazuje się komunikat.

Wiemy z niego, że strona o końcówce “website32325”, jeśli nie istnieje, jest parsowana do komunikatu. Po podmianie końcówki na <script>alert(1);</script>, jeśli nie jest ona w żaden sposób szyfrowana, na stronie powinien wywołać się komunikat.

Dom Based XSS (Type 0)

Wstrzyknięcie złośliwego kodu następuje po stronie klienta. Oznacza to dla nas, że po otwarciu strony, nie ma początkowo na niej nic podejrzanego, jak jest w przypadku Reflected XSS. Dopiero po wejściu na nią następuje modyfikacja elementu DOM za pośrednictwem np. wcześniej spreparowanego przez atakującego parametru w url. Poniższy przykład ze strony OWASP ilustruje ten typ ataku.

Formularz języka na naszej stronie jest przygotowany w poniższy sposób:

<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ślnie, w parametrze default, znajduje się język polski.

http://www.dummy-website.com/page.html?default=Polish

Jeśli parametr nie jest szyfrowany, po zmianie go, nastąpi uaktywnienie skryptu.

http://www.dummy-website.com/page.html?default=<script>alert(1);</script>

Server side XSS

Jedna z podstron jest generowana dynamicznie, a w jednym z pól wyświetlana jest nazwa użytkownika. Jeśli użytkownik może ustawić swoją nazwę użytkownika jako <script>alert(1);</script> i nie jest to w żaden sposób szyfrowane, a nam po zapisaniu wyświetli się komunikat, oznacza to, że XSS się powiódł.

Client side XSS

Na stronie, nad którą pracujemy, zauważamy, że po wypełnieniu pola w wyszukiwaniu, tekst z niego jest parsowany do htmla między tagi, które zmieniają tekst na czerwono. Możemy zaatakować użytkownika w taki sposób, aby między tagami znalazł się czerwony tekst, informujący użytkownika o tym, że jest to błąd serwera i powinien udać się na wskazaną stronę. W momencie wejścia na nią, uaktywnia się uprzednio przygotowany skrypt atakującego.