Cross-Site Scripting (XSS)

Cross-site scripting – określany jako XSS – to luka w aplikacji, która może potencjalnie siać spustoszenie w aplikacjach i witrynach internetowych. XSS jest tak powszechny i potencjalnie szkodliwy, że wciąż znajduje się na liście 10 największych luk Open Web Application Security Project (OWASP).

W rzeczywistości Cross-Site Scripting jest najczęściej wykrywaną podatnością od 2014 roku, a w 2019 roku nadal pojawia się w Top 3 zgłaszanych podatności.

W niektórych przypadkach, skrypt po stronie przeglądarki może również wprowadzić tę lukę, pozwalając atakującemu na jej wykorzystanie bez konieczności wysyłania przez użytkownika docelowego żądania do aplikacji webowej.

Atakujący wykorzystują XSS poprzez spreparowanie złośliwego kodu, który może zostać skierowany do innego użytkownika, a następnie wykonany przez niczego nie podejrzewającą przeglądarkę. Ponieważ skrypt jest najczęściej zawarty w treści odpowiedzi aplikacji internetowej, jest on wykonywany i ma taki sam dostęp, jak gdyby skrypt był legalny. Może uzyskać dostęp do tokenów sesji, plików cookie, a nawet poufnych lub wrażliwych informacji, do których przeglądarka ma dostęp na danej stronie, a nawet przepisać zawartość strony HTML.

Odbite ataki XSS

W odbitych atakach XSS, złośliwy skrypt jest wstrzykiwany do żądania HTTP (zwykle przez specjalnie spreparowany link dostarczony użytkownikowi). W najprostszej odmianie wykorzystuje on parametry wejściowe w żądaniu HTTP, które można łatwo zmanipulować, aby zawierały szkodliwą zawartość skryptu. Złośliwy skrypt jest następnie odbijany od serwera w odpowiedzi HTTP i wykonywany w przeglądarce ofiary.

W tym przypadku działa on jak przechowywany XSS bez faktycznego przechowywania złośliwych danych na serwerze.

Oto przykład ataku Reflected XSS:

Powiedzmy, że example.com/profile zawiera parametr name. Adres URL dla żądania wyglądałby następująco: https://example.com/profile?user=Tammy. Na podstawie tych danych wejściowych, aplikacja internetowa odpowiedziałaby „Hi Tammy” na górze strony. Jeśli parametry nie są walidowane, aby zapewnić, że zawierają tylko oczekiwane dane, atakujący mógłby spowodować, że użytkownik odwiedziłby złośliwą wersję adresu URL, taką jak ta: https://example.com/profile?user<script>some_malicious_code</script>.

Gdy odpowiedź jest wysyłana do przeglądarki, zawiera ona ten złośliwy skrypt, który jest następnie wykonywany w przeglądarce, prawdopodobnie nawet bez wiedzy użytkownika. Jest to przykład odbitego ataku XSS, ponieważ złośliwy kod jest natychmiast „odbijany” z powrotem do użytkownika zgłaszającego żądanie.

Zapisane ataki XSS

W tak zwanym zapisanym lub trwałym ataku XSS, złośliwa zawartość jest dostarczana bezpośrednio, wraz z odpowiedzią serwera, gdy użytkownik ładuje stronę internetową. W ten sposób treść jest już przechowywana w bazie danych witryny (stąd nazwa dla tego typu ataków). Użytkownicy po prostu wchodzą na zhakowaną stronę internetową i padają ofiarą takich ataków.

Każdy użytkownik, który otworzy taką skompromitowaną stronę internetową jest więc narażony na ryzyko kradzieży swoich danych osobowych, a więc można to uznać za najbardziej niebezpieczny rodzaj ataku XSS.

Ale jak złośliwa treść dostaje się do bazy danych na początek? W większości przypadków jest ona wprowadzana poprzez niezabezpieczone formularze stron internetowych, w których dane wejściowe użytkownika nie są odpowiednio walidowane i oczyszczane. Jeśli dane wprowadzone przez hakera nie zostaną zwalidowane zarówno po stronie klienta, jak i serwera, zostaną zapisane w bazie danych. Na przykład, takie dane wejściowe mogą zawierać obszar tekstowy komentarza, edytor tekstu postu, edytor danych osobowych lub inne formularze.

Od momentu, gdy atakującemu uda się wysłać złośliwą zawartość do serwera i ta zawartość pojawi się na stronie internetowej bez filtrowania, wszyscy użytkownicy stają się potencjalnymi ofiarami.Powszechnym środkiem zaradczym na przechowywane ataki XSS jest sanityzacja danych wejściowych zarówno po stronie front-end, jak i back-end aplikacji. Sanityzacja obejmuje kombinację walidacji danych i ucieczki od znaków specjalnych lub całkowitego ich odfiltrowania i jest powszechną najlepszą praktyką w zakresie bezpieczeństwa stron internetowych i JavaScript.

Ataki XSS oparte na DOM

Document Object Model (DOM) jest interfejsem, który umożliwia aplikacjom odczytywanie i manipulowanie strukturą strony internetowej, jej zawartością i stylem. W ataku XSS opartym na DOM, luka leży w kodzie skryptu po stronie przeglądarki i może zostać wykorzystana bez żadnej interakcji z serwerem, modyfikując środowisko przeglądarki niczego niepodejrzewającej ofiary.

Niekiedy ataki XSS oparte na DOM są podobne do ataków odbitych. Powyższy przykład odbitego ataku XSS można zastosować w tym przypadku przy jednym założeniu: Aplikacja internetowa odczytuje dane bezpośrednio z ciągu zapytania.

Powiedzmy, że aplikacja używa parametru zapytania „name” w celu natychmiastowego wyświetlenia na ekranie imienia użytkownika w oczekiwaniu na załadowanie się reszty strony. Bez odpowiedniej walidacji może to przynieść taki sam rezultat, jak w przypadku ataku odbitego, jeśli hakerowi uda się skłonić ofiarę do otwarcia podejrzanego linku.

Tak jak w przypadku przechowywanego XSS, aby zapobiec atakom odbitym i opartym na DOM, programiści powinni wdrożyć walidację danych i unikać wyświetlania surowych danych wejściowych użytkownika, niezależnie od obecności lub braku komunikacji z serwerem.

Jakie są wektory ataku Cross-site Scripting?

W atakach XSS powszechnie wykorzystuje się kilka wektorów:

• <znacznik script>: Znacznik script może być użyty do odwołania się do zewnętrznego kodu JavaScript, co sprawia, że jest to najprostszy punkt XSS. Atakujący mogą również osadzić złośliwy kod wewnątrz znacznika script.
• Zdarzenia JavaScript: Inny popularny wektor XSS wykorzystywany przez atakujących, atrybuty zdarzeń, mogą być stosowane w różnych znacznikach. Przykładem są takie atrybuty jak „onerror” i „onload”.
• <znacznikbody>: Atrybuty zdarzeń mogą być również źródłem skryptu, gdy są dostarczane poprzez znacznik „body”.
• <img> znacznik: W zależności od używanej przeglądarki, atrybut ten może być przydatny przez atakujących do wykonania kodu JavaScript.
• <iframe> znacznik: Szczególnie skuteczny w przypadku ataków phishingowych, wektor ten pozwala atakowi XSS na osadzenie innej strony HTML w bieżącej stronie.
• <input> tag: Niektóre przeglądarki pozwalają na manipulację poprzez ten wektor, który może być wykorzystany do osadzenia skryptu.
• <znaczniklink>: Ten znacznik może zawierać skrypt, zamiast normalnego stosowania odnośników do zewnętrznych arkuszy stylów.
• <znacznik table>: Tam, gdzie atrybut background normalnie odnosi się do obrazu, może on zostać skompromitowany, aby odnosić się do obraźliwego skryptu.
• <znacznikdiv>: Ten znacznik również zawiera odwołanie do tła i może być użyty w taki sam sposób jak <table> do odwołania się do skryptu.
• <object> znacznik: Skrypty z zewnętrznej witryny mogą być dołączane za pomocą tego znacznika.

Pomimo że istnieją inne wektory, które napastnicy XSS wykorzystują w swoich wysiłkach wykradania informacji i kompromitowania witryn, są to jedne z najczęściej stosowanych metod. Programiści muszą stosować się do odpowiednich praktyk ucieczki i sanityzacji, aby uchronić się przed takimi atakami.

Powiedzmy, że exmple.com/profile zawiera parametr name. Adres URL dla żądania wyglądałby jak https://example.com/profile?user=Tammy. Aplikacja internetowa odpowiada „Cześć Tammy” na górze strony na podstawie tych danych wejściowych.

Jeśli parametr użytkownika nie zostanie zweryfikowany w celu zapewnienia, że zawiera tylko oczekiwane dane, atakujący może spowodować, że użytkownik odwiedzi złośliwą wersję adresu URL, która wygląda tak:
https://example.com/profile?user<script>some_malicious_code</script>.
Gdy odpowiedź jest wysyłana do przeglądarki, zawiera ten złośliwy skrypt, który jest następnie wykonywany w przeglądarce, prawdopodobnie nawet bez wiedzy użytkownika. Jest to przykład odbitego ataku XSS. Złośliwy kod jest natychmiast „odbijany” z powrotem do użytkownika zgłaszającego żądanie.

• Edukacja i świadomość: Upewnij się, że wszyscy programiści, projektanci stron internetowych i zespoły QA są świadomi metod, jakie hakerzy stosują w celu wykorzystania luk w zabezpieczeniach oraz zapewnij wytyczne i najlepsze praktyki kodowania. Obejmuje to odpowiednie techniki ucieczki/kodowania dla środowiska aplikacji (JavaScript, HTML, itp.).
• Sanitize input: Niezależnie od tego, czy chodzi o wewnętrzne strony internetowe, czy witryny publiczne, nigdy nie ufaj ważności danych wejściowych użytkownika. Prześwietl i zweryfikuj wszystkie pola danych, zwłaszcza jeśli będą one zawarte jako dane wyjściowe HTML.
• Skanowanie kodu: Wdrażaj oprogramowanie, które skanuje kod pod kątem luk, w tym cross-site scripting, aby zapewnić, że najlepsze praktyki są przestrzegane i minimalizuje narażenie na XSS i inne podatności z listy OWASP.
• Content Security Policy: Użyj Content Security Policy (CSP), aby zdefiniować, co witryna może robić, a przez to zmniejszyć ryzyko ataku XSS. Dzięki zastosowaniu CSP, XSS może zostać całkowicie zablokowany (poprzez zablokowanie wszystkich skryptów in-line) lub zredukowany do znacznie niższego ryzyka.

OWASP dostarcza dodatkowych wskazówek, jak zapobiegać podatności XSS za pomocą obszernego cheat sheet.