Cross Site Scripting, czyli w skrócie XSS, to rodzaj ataku na aplikacje webowe poprzez użycie formularza zawartego na stronie internetowej lub adresu URL takiej aplikacji. Najczęściej do jego przeprowadzenia wykorzystywane są skryptowe języki programowania, takie jak JavaScript czy PHP.

Sam atak polega na osadzeniu w treści atakowanej strony kodu (skryptu), który jest wykonywany podczas wyświetlania strony internetowej poszczególnym użytkownikom i może prowadzić do niepożądanych akcji, np. w celu obejścia niektórych mechanizmów kontroli dostępu do danych użytkownika.

Ogólnie o XSS

Ataki XSS są bardzo groźne, ponieważ mogą prowadzić do dewastacji danej strony internetowej, czy kradzieży haseł lub innych danych używanych do logowania.

Z uwagi na to że współcześnie większość stron internetowych jest tworzona „w locie” podczas ich ładowania, a częstokroć kod wykonywany jest w samej przeglądarce, zapobieganie tego rodzaju atakom stanowi spore wyzwanie dla osób odpowiedzialnych za bezpieczeństwo aplikacji webowych.

O wadze problemu świadczy fakt, że w raporcie OWASP TOP 10 2021 (artykuł możesz przeczytać tutaj) ten rodzaj ataku zajął trzecie miejsce przesuwając się w górę o cztery pozycje w porównaniu do raportu z 2017 roku.

Mechanizm działania

Atak Cross Site Scripting polega na wykonaniu złośliwego kodu podczas wejścia na zaatakowaną witrynę przez przeglądarkę ofiary (stąd pochodzi wyraz „cross”, tj. krzyżować, w nazwie tego ataku). Aktualnie hakerzy nie muszą uzyskiwać uprzywilejowanego dostępu do serwera www, na którym umieszczona jest dana strona, w celu wstrzyknięcia złośliwego kodu. Zamiast tego atakujący wykorzystują sposób działania nowoczesnych stron internetowych, które tworzone są dynamicznie, czyli nie wyświetlają tego samego statycznego kodu HTML każdemu użytkownikowi, ale są tworzone na bieżąco na podstawie informacji zawartych w bazie danych serwera wówczas, gdy przeglądarka zażąda dostępu. To, jaką stronę otrzyma przeglądarka w odpowiedzi od serwera, zależy od informacji przesłanych wraz z żądaniem, które często przyjmują postać parametrów w adresie URL, który jest używany do uzyskania dostępu do danej strony internetowej czy aplikacji webowej.

Należy wskazać, że nowoczesne strony internetowe składają się nie tylko z kodu HTML i kaskadowych arkuszy stylów, czyli CSS, których zadaniem jest opisywanie sposobu renderowania tekstu i grafiki, ale zawierają również kod wykonywalny napisany w językach skryptowych, przeważnie w języku JavaScript. Łączenie w niniejszy sposób danych, prezentacji i kodu wykonywalnego stało się podatnością umożliwiającą przeprowadzanie ataków XSS w szczególności, gdy witryna internetowa prezentuje tekst przekazany przez użytkownika jako kod HTML tej witryny, bez uprzedniej konwersji tekstu na HTML, co zachodzi poprzez zamianę specjalnych znaków HTML na encje.

Występowanie ataków XSS i ich rodzaje

Wyróżnia się trzy rodzaje ataków XSS, mianowicie:

1) XSS reflected (non-persistent XSS, atak odbity, nietrwały), który polega na prezentacji treści zawierającej spreparowany skrypt wyłącznie w odpowiedzi na konkretne zapytanie konkretnego użytkownika, wobec czego może być wykorzystany tylko wobec pojedynczych ofiar. Atak ten jest często połączony z phishingiem, w ramach którego atakujący nakłania ofiarę do wejścia w podany, np. w wiadomości e-mail lub SMS, link uruchamiający złośliwy kod. Przykładowy kod strony podatny na ataki XSS reflected może wyglądać następująco:

https://insecure-website.com/status?message=All+is+well.

<p>Status: All is well.</p>

Znając tą podatność atakujący może wykorzystać następujący skrypt:

https://insecure-website.com/status?message=<script>/*+Malicious+code+here…+*/</script>

<p>Status: <script>/* Malicious code here… */</script></p>

Taki skrypt zostanie uruchomiony w przeglądarce ofiary i wykona zaprogramowane przez hakera zadania w miejscu „Malicious code here…”.

2) XSS stored (persistent XSS, atak uporczywy), który polega na wykorzystaniu interaktywnych funkcji witryny i zapamiętaniu przez serwis przesłanej przez atakującego treści (skryptu zawierającego złośliwy kod) i prezentacji jej kolejnym odwiedzającym (np. na forum internetowym), wobec czego tego typu atak może posłużyć do naruszenia bezpieczeństwa kont tysięcy użytkowników. Przykładowy kod strony podatny na ataki XSS stored może wyglądać następująco – w naszym przykładzie aplikacja poprzez tablicę ogłoszeń umożliwia użytkownikom przesyłanie wiadomości, które są wyświetlane innym użytkownikom:

<p>Hello, this is my message!</p>

Z uwagi na to, że aplikacja nie wykonuje żadnego innego przetwarzania danych wejściowych, haker może łatwo wysłać wiadomość zawierającą kod atakujący innych użytkowników:

<p><script>/* Malicious code here… */</script></p>

Taki skrypt zostanie uruchomiony w przeglądarce każdego użytkownika odwiedzającego tą aplikację i wykona zaprogramowane przez hakera zadania w miejscu „Malicious code here…”.

3) ataki oparte na DOM (ang. Document Object Model), czyli znormalizowanym interfejsie API, który definiuje sposób, w jaki przeglądarki budują stronę www z bazowego kodu HTML lub JavaSript; ten rodzaj ataku jest odmianą XSS reflected, jednakże w tym przypadku złośliwy kod nie jest wysyłany na serwer przechowujący atakowaną witrynę. Zamiast tego skrypt zawierający złośliwy kod jest przekazywany jako parametr do konkretnej funkcji JavaScript wykonywanej w samej przeglądarce, a tym samym mechanizmy obronne po stronie serwera nie są w stanie ochronić użytkownika.

Przykładowy kod strony podatny na ten typ ataków XSS – w naszym przykładzie aplikacja używa kodu JavaScript do odczytania wartości z pola wejściowego i zapisania tej wartości do elementu w kodzie HTML:

var search = document.getElementById(’search’).value;

var results = document.getElementById(’results’);

results.innerHTML = 'You searched for: ’ + search;

Jeśli atakujący może kontrolować wartość pola wejściowego, to może łatwo skonstruować złośliwą wartość, która spowoduje wykonanie własnego skryptu:

You searched for: <img src=1 onerror=’/* Malicious code here… */’>

W typowym przypadku pole wejściowe byłoby wypełniane na podstawie części żądania HTTP, na przykład parametru ciągu zapytania adresu URL, umożliwiając atakującemu przeprowadzenie ataku przy użyciu złośliwego adresu URL w taki sam sposób, jak w przypadku ataku XSS reflected.

Warto jeszcze zaznaczyć, że szeregowa struktura dokumentów HTML i trudność w oddzieleniu kodu JavaScript od znaczników kontrolujących prezentację treści, a także wady zawartych w JavaScript mechanizmów zabezpieczeń, sprawiają że podatności na ataki XSS są niezwykle częstym problemem we współczesnych dynamicznych stronach www, zwłaszcza w tak zwanych stronach „Web 2.0”, a wyeliminowanie tych podatności wymaga dużej staranności.

Czasami też, w przypadku gdy dana aplikacja webowa nie umożliwia użytkownikom dodawania treści, atakujący wykorzystują lukę typu SQL Injection do przeprowadzenia ataku XSS stored (XSS persistent). Taki atak umożliwia zmianę danych zapisanych w bazie danych, a w konsekwencji przyczynia się do rozprzestrzeniania skryptu zawierającego złośliwy kod na wszystkich użytkowników takiej strony internetowej.

Polityka tego samego pochodzenia i konsekwencje udanego ataku XSS

Zaznaczyć należy, że przeglądarki internetowe udostępniają wykonywanym na danej stronie internetowej skryptom jedynie obiekty pochodzące z tego samego źródła co dana strona. Jednocześnie przeglądarki posługują się przy tym zasadą tożsamego pochodzenia (same origin policy) zdefiniowaną jako kombinacja schematu URI, nazwy hosta i numeru portu. Zasada ta zezwala na dostęp do zasobów stron, których adres posługuje się takim samym protokołem, nazwą domeny serwera i numerem portu, co wyraźnie jest uwidocznione w poniższej tabeli dla przykładowego adresu „http://xyz.com/path/index.html”:

Warto zaznaczyć, że jeśli złośliwy kod ze skryptu zostanie uruchomiony w przeglądarce, podczas gdy ofiara wchodzi na atakowaną stronę internetową, wówczas przeglądarka pozwoli takiemu skryptowi uzyskać dostęp do danych z innych stron, które mają wspólne źródło ze stroną podatną na ataki. Wówczas skrypt zawierający złośliwy kod może zmieniać wygląd strony, ale także może mieć dostęp do ciasteczek i innych zastrzeżonych informacji o sesji, co w prosty sposób może prowadzić do włamania na konta internetowe ofiary. Ponadto haker może:

– przejąć kontrolę nad całą funkcjonalnością takiej aplikacji webowej,

– mieć dostęp do wszystkich zawartych w niej danych,

– podszywać się lub udawać użytkownika będącego ofiarą,

– wykonywać dowolną czynność, którą użytkownik może wykonać,

– odczytać wszelkie dane, do których użytkownik ma dostęp,

– przechwycić dane logowania użytkownika,

– dokonać wirtualnego zniszczenia strony internetowej,

– wstrzyknąć do witryny internetowej kod zawierający konia trojańskiego.

Jako ciekawostkę warto wskazać, że gdyby taki sam złośliwy kod został umieszczony na innej stronie niż zaatakowana, wówczas przeglądarka ofiary odmówiłaby takiemu wykonywującemu się skryptowi ze złośliwym kodem dostępu do zasobów związanych z atakowaną witryną.

Wskazać należy, że rzeczywisty wpływ ataku XSS zasadniczo zależy od charakteru aplikacji, jej funkcjonalności i danych oraz statusu zaatakowanego użytkownika. Na przykład:

– w aplikacji broszurowej, w której wszyscy użytkownicy są anonimowi, a wszystkie informacje są publiczne, wpływ będzie często minimalny, natomiast

– w aplikacji przechowującej poufne dane, takie jak transakcje bankowe, e-maile lub dane medyczne, wpływ będzie zwykle poważny, a

– jeżeli ofiara ma podwyższone uprawnienia w aplikacji, wpływ będzie na ogół krytyczny, umożliwiający atakującemu przejęcie pełnej kontroli nad podatną aplikacją i zagrażający wszystkim użytkownikom i ich danym.

Zapobieganie atakom XSS

W celu zapobiegania atakom Cross Site Scripting należy stosować sanityzację danych wejściowych, czyli nieakceptowanie kodu zawartego w przesłanym skrypcie bezpośrednio jako danych wejściowych poprzez ich niefiltrowanie lub nieodpowiednie filtrowanie. Jednakże z uwagi na to, że hakerzy znajdują coraz to nowe sposoby na ominięcie filtrów, zasadnym jest stosowanie tzw. „białej listy”, czyli akceptowanie przez aplikację danych w ściśle określonych formatach, np. numery telefonów, czy adresy e-mail i tylko w oczekiwanych przypadkach.

Kolejną możliwością zabezpieczenia się przed atakiem XSS jest ucieczka danych wyjściowych, która polega na wysyłaniu przez aplikację danych wprowadzonych przez użytkownika z powrotem na stronę www. Dane te powinny być odpowiednio filtrowane, aby mieć pewność, że nie są one kodem wykonywalnym dla tej strony internetowej. Jeżeli użytkownik wprowadza jako dane wejściowe znaczniki HTML, aplikacja powinna używać znaków ucieczki, aby te znaczniki pojawiały się jako tekst na stronie internetowej, a nie były zintegrowane z jej kodem HTML.

Ponadto broniąc się przed potencjalnym atakiem XSS można oprzeć się na standardzie CSP (Standard Content Security Policy), który polega na takiej budowie aplikacji, aby wykonywała tylko ten kod, który został określony jako bezpieczny. Wobec tego można stwierdzić, że jest to rozszerzone podejście do „białej listy” wykraczające poza tekst wejściowy do sfery wykonywania skryptów.

Ponadto w celu zapobiegania atakom XSS można zastosować Dangling markup injection, czyli technikę, której można użyć do przechwytywania danych między domenami w sytuacjach, w których pełne wykorzystanie skryptów między witrynami nie jest możliwe ze względu na filtry wejściowe lub inne zabezpieczenia. Często tę technikę można wykorzystać do przechwytywania poufnych informacji, które są widoczne dla innych użytkowników, w tym tokenów CSRF, które można wykorzystać do wykonywania nieautoryzowanych działań w imieniu użytkownika.

Warto zaznaczyć, iż niezwykle ważne jest testowanie aplikacji webowych pod kątem podatności na ataki XSS. Pomocne są w tym zasoby zgromadzone przez organizację OWASP oraz regularne prowadzenie testów penetracyjnych.

Odnajdywanie podatności na ataki XSS

Zdecydowaną większość luk w zabezpieczeniach XSS można znaleźć szybko i niezawodnie za pomocą prowadzenia testów manualnych, testów penetracyjnych lub internetowego skanera luk w zabezpieczeniach, np. Burp Suite.

Ręczne testowanie podatności na ataki XSS reflected oraz XSS stored zwykle polega na przesłaniu prostych, unikalnych danych wejściowych (takich jak krótki ciąg alfanumeryczny) do każdego punktu wejścia w aplikacji, zidentyfikowaniu każdej lokalizacji, do której przesłane dane wejściowe są zwracane w odpowiedziach HTTP oraz indywidualnym przetestowaniu każdej lokalizacji w celu określenia czy odpowiednio spreparowane dane wejściowe mogą być użyte do wykonania dowolnego kodu JavaScript. W ten sposób można określić kontekst, w którym występuje podatność na atak XSS i wybrać odpowiedni ładunek, aby go wykorzystać.

Ręczne testowanie podatności na atak XSS oparty na modelu DOM, wynikający z parametrów adresu URL, obejmuje podobny proces, czyli: umieszczanie prostych unikalnych danych wejściowych w parametrze, używanie narzędzi programistycznych przeglądarki do wyszukiwania danych wejściowych w modelu DOM oraz testowanie każdej lokalizacji w celu określenia, czy można ją wykorzystać. Jednak inne typy DOM XSS są trudniejsze do wykrycia. Aby znaleźć luki w zabezpieczeniach DOM w danych wejściowych nieopartych na adresach URL (takich jak document.cookie) lub ujściach nieopartych na HTML (takich jak setTimeout), należy przeglądać kod JavaScript, co może być niezwykle czasochłonne. Pomocne są tutaj skanery podatności sieci, np. Burp Suite, łączące statyczną i dynamiczną analizę JavaScript, aby niezawodnie zautomatyzować wykrywanie luk w zabezpieczeniach opartych na modelu DOM.

XSS a CSRF – różnice

Z uwagi na podobieństwo oba rodzaje ataków są często ze sobą mylone. Jednakże w rzeczywistości znacząco się od siebie różnią. Dokładne wyjaśnienie czym jest atak CSRF znajdziesz w tym artykule.

Generalnie można stwierdzić, że oba ataki są skierowane na przeglądarkę użytkownika, przy czym atak cross-site request forgery (CSRF) wykorzystuje uwierzytelnioną sesję użytkownika, np. sesję, w której użytkownik jest zalogowany do swojej bankowości elektronicznej, podczas gdy atak XSS nie potrzebuje uwierzytelnionej sesji dla swojej skuteczności.

Słynne ataki XSS

Jeden z najgłośniejszych ataków XSS miał miejsce w 2005 roku, kiedy to Samy Kamkar użytkownik platformy MySpace wstawił do swojego profilu kod JavaScript, który automatycznie zaprzyjaźniał się z każdym odwiedzającym stronę. Ponadto skopiował ten kod do profili swoich nowych znajomych, dzięki czemu każdy kto odwiedził strony nowych znajomych Kamkara zaprzyjaźnił się również z nim. W ciągu 24 godzin Kamkar zdobył ponad milion znajomych i zmusił MySpace do krótkotrwałego wyłączenia całej witryny.

Innymi atakami były:

– przeprowadzony w 2019 roku atak XSS, podczas którego hakerzy ukradli V-Bucks graczom Fortnite,

– przeprowadzony w 2019 roku atak XSS grupy hakerów Magecart na British Airways prowadzący do wykradzenia setek tysięcy tożsamości klientów tej linii lotniczej.

Warto odnotować, że od 2021 roku luki w zabezpieczeniach podatne na atak XSS zostały odnalezione na platformie poczty elektronicznej Zimbra, platformie WordPress i otwartoźródłowej platformie zarządzania IT Nagios.

Jednakże hakerzy zazwyczaj nie przeprowadzają tylko samego ataku XSS, który stał się jednym z elementów złożonej formy ataku wykorzystującej certyfikaty TLS typu wildcart, zwanej ALPACA.

Podsumowanie

Ataki XSS stają się coraz groźniejsze o czym świadczy zajęcie trzeciego miejsca w raporcie OWASP TOP 10, także poprzez coraz częstsze wykorzystywanie przez hakerów podatności aplikacji webowych na ataki XSS w ramach szerzej zakrojonych i bardziej skomplikowanych ataków przeciwko poszczególnym przedsiębiorstwom czy organizacjom.

Ponadto dynamika zmian, a tym samym nowatorskie podejście do tworzenia i wyświetlania stron internetowych, powodują powstawanie luk w zabezpieczeniach i sprzyjają skutecznie przeprowadzanym atakom XSS.

Jednakże cały czas rozwijająca się branża bezpieczeństwa cybernetycznego i pojawiające się coraz to nowe możliwości obrony przed atakami XSS pozwalają śmielej patrzeć w przyszłość i budować zwiększające się zaufanie użytkowników do aplikacji webowych.

Autor: Michał Mamica