Cross-site scripting (XSS) to cyberatak, w którym haker wprowadza złośliwy kod do formularza internetowego lub adresu url aplikacji internetowej. Ten złośliwy kod, napisany w języku skryptowym, takim jak JavaScript lub PHP, może zrobić wszystko - od zdewastowania strony, którą próbujesz załadować, po kradzież Twoich haseł lub innych danych logowania.

XSS wykorzystuje ważny aspekt współczesnego Internetu, a mianowicie fakt, że większość stron internetowych jest tworzona w locie podczas ładowania stron, czasami poprzez wykonywanie kodu w samej przeglądarce. Może to utrudniać zapobieganie takim atakom.

Zobacz również:

• Apple ostrzega użytkowników w 92 krajach. Uwaga na ataki szpiegowskie

Jak działa atak XSS

Każdy może utworzyć witrynę zawierającą złośliwy kod. W przypadku ataku typu cross-site scripting atakujący ustawia wszystko tak, aby jego kod dostał się na komputer ofiary, gdy ta wejdzie na cudzą witrynę. Stąd właśnie pochodzi „cross” (skrzyżować) w nazwie. Atakom XSS udaje się to osiągnąć bez konieczności uzyskiwania uprzywilejowanego dostępu do serwera WWW w celu ukradkowego umieszczenia na nim kodu. Zamiast tego atakujący wykorzystują sposób działania nowoczesnych stron internetowych.

Gdyby ktoś poprosił Cię o podstawowe, proste wyjaśnienie działania sieci, prawdopodobnie powiedziałbyś mu coś takiego: osoba, która chce stworzyć stronę WWW, pisze dokument HTML, który umieszcza na serwerze WWW; kiedy użytkownik chce uzyskać dostęp do tej strony, kieruje swoją przeglądarkę pod adres serwera, a przeglądarka pobiera kod HTML i interpretuje go, budując wersję strony WWW dla użytkownika.

Opis ten nie jest błędny, ale pewne jego aspekty są przestarzałe (i to już od ponad dziesięciu lat). Po pierwsze, wiele, jeśli nie wszystkie, strony WWW są obecnie dynamiczne - to znaczy, że nie wyświetlają tego samego statycznego kodu HTML każdemu odwiedzającemu, ale raczej są tworzone na bieżąco na podstawie informacji zawartych w bazie danych serwera, gdy przeglądarka zażąda dostępu. To, jaką stronę przeglądarka otrzyma z powrotem od serwera, często zależy od informacji przesłanych wraz z żądaniem - informacji, które czasami przyjmują postać parametrów w adresie URL użytym do uzyskania dostępu do witryny. Witryny internetowe składają się nie tylko z kodu HTML i kaskadowych arkuszy stylów (CSS), które opisują sposób renderowania tekstu i grafiki, ale zawierają również kod wykonywalny napisany w językach skryptowych, zwykle w języku JavaScript. Łączenie w ten sposób danych, prezentacji i kodu wykonywalnego jest swego rodzaju „grzechem pierworodnym” bezpieczeństwa sieciowego.

W ataku XSS haker wykorzystuje tę interakcję między użytkownikiem a witryną, aby wykonać na komputerze użytkownika złośliwy kod. Ale jak? Weźmy pod uwagę następujący adres URL:

https://www.google.com/search?q=CSO+online

Wpisz to w pasku adresu przeglądarki, a zobaczysz wyniki wyszukiwania Google dla hasła „CSO Online”. W rzeczywistości strona, którą zobaczysz, wygląda dokładnie tak samo, jak gdybyś wpisał „CSO Online" w pasku wyszukiwania przeglądarki lub na stronie głównej Google. Zauważysz między innymi, że fraza ta pojawia się w kilku miejscach na stronie, w tym na pasku wyszukiwania u góry:

Co by się stało, gdyby zamiast niewinnej i zdrowej frazy „CSO online” ten adres URL zawierał złośliwy kod JavaScript, taki jak ten?

https://www.google.com/search?<script>doEvil()</script>

doEvil() pełni tutaj rolę naprawdę paskudnej funkcjonalności. Możesz się obawiać, że Google, zamiast wyświetlać „CSO Online” na stronie, którą zwróci z tego adresu URL, zamiast tego włączy ten zły JavaScript do strony, którą dynamicznie wyrenderuje, a ten skrypt następnie wykona się w przeglądarce, siejąc spustoszenie. Wasze obawy byłyby bezpodstawne, ponieważ Google ma wśród swoich pracowników całkiem sporo utalentowanych specjalistów od bezpieczeństwa IT i wdrożyło środki zaradcze, o których za chwilę opowiemy. Jednak nie każda witryna jest tak ostrożna, a to daje wyobrażenie o tym, jak mogą działać takie ataki.

Ataki XSS

Ataki XSS dzielą się na kilka kategorii: ataki odbite, ataki oparte na DOM oraz ataki przechowywane. Oto czym się różnią:

• Ataki odbite: zwane także nietrwałymi polegają na tym, że złośliwy kod JavaScript został wysłany z przeglądarki ofiary do Google, a następnie odbity z powrotem w formie wykonywalnej i nigdy nie jest trwale przechowywany na serwerach Google. Ataki te są często częścią oszustwa typu phishing, gdzie szkodliwe łącze jest zamaskowane jako coś bardziej przyjemnego i wysyłane do ofiary pocztą elektroniczną lub SMS-em.
• Ataki oparte na DOM: jest to odmiana ataku odbitego, której nazwa pochodzi od Modelu Obiektów Dokumentu (ang. Document Object Model) - znormalizowanego interfejsu API, który definiuje sposób, w jaki przeglądarki budują stronę WWW z bazowego kodu HTML lub JavaScript. Większość ataków opartych na DOM jest podobna do opisanego wcześniej ataku odbitego, z tą różnicą, że złośliwy kod nigdy nie jest wysyłany na serwer: zamiast tego jest przekazywany jako parametr do jakiejś funkcji JavaScript, która jest wykonywana w samej przeglądarce, co oznacza, że mechanizmy obronne po stronie serwera nie są w stanie ochronić użytkownika. Jeśli jesteście zainteresowani szczegółami, PortSwigger ma bardziej szczegółowy opis działania ataków opartych na DOM.
• Ataki przechowywane: inaczej uporczywe; atakujący wykorzystuje interaktywne funkcje witryny do zapisania złośliwego kodu na serwerze WWW. W typowym przykładzie, atakujący zostawia komentarz do wpisu na blogu, który zawiera złośliwy JavaScript. Następnym razem, gdy ktoś załaduje tę stronę, kod ten zostanie wykonany.
• Podatność na atak XSS

Co sprawia, że witryna jest podatna na atak XSS? Mamy nadzieję, że nasza dotychczasowa dyskusja dostarczyła Ci wskazówek. Jeśli Twoja aplikacja internetowa naiwnie pobiera dane wejściowe od użytkownika, nie sprawdza ich pod kątem potencjalnie złośliwego kodu wykonywalnego i wykorzystuje te dane do renderowania strony lub wykonywania innych operacji, jest podatna na tego typu atak.

A stawka jest wysoka. Kluczowym aspektem bezpieczeństwa przeglądarki jest tzw. polityka tego samego pochodzenia, która mówi, że skrypt wykonujący się na jednej stronie może uzyskać dostęp do danych na drugiej stronie tylko wtedy, gdy obie strony mają to samo pochodzenie (zdefiniowane jako kombinacja schematu URI, nazwy hosta i numeru portu). Jeśli jednak złośliwy JavaScript może zostać uruchomiony w przeglądarce, podczas gdy ofiara wchodzi na stronę internetową, przeglądarka pozwoli temu JavaScriptowi uzyskać dostęp do danych z innych stron, które mają wspólne źródło ze stroną podatną na ataki. Taki JavaScript może uzyskać dostęp do ciasteczek i innych zastrzeżonych informacji o sesji, co stanowi dobry przepis na włamanie się na konta internetowe ofiary.

Payloads XSS

W języku złośliwego oprogramowania, payload to kod wykonywalny, który wykonuje działania pożądane przez atakującego. W przypadku ataku XSS, ładunek jest kodem skryptu, który atakujący zdoła podstępnie zmusić przeglądarkę ofiary do wykonania.

W repozytorium payloadbox na GitHubie znajduje się ogromna lista przykładowych ładunków XSS. Jeśli znasz JavaScript, przejrzenie ich może dać Ci wyobrażenie o tym, jak atakujący XSS wykonują swoją brudną robotę. Jednak atak XSS wykracza daleko poza wycięcie i wklejenie ładunku do adresu URL: atakujący musi zrozumieć specyficzną funkcjonalność i luki w aplikacji internetowej, którą chce wykorzystać, aby zaplanować atak. Jeśli chcesz zagłębić się w temat i zobaczyć kilka przykładów ataków XSS, sprawdź stronę fundacji OWASP poświęconą XSS, która dogłębnie omawia kod skryptu ilustrujący atak XSS.

Ochrona i zapobieganie XSS

Jeśli tworzysz lub obsługujesz aplikację internetową lub interaktywną witrynę, powinieneś uwzględnić w projekcie trzy główne techniki, które pozwolą Ci uniknąć potencjalnych ataków typu cross-site scripting.

• Sanityzacja danych wejściowych. Oczywistą odpowiedzią na zapobieganie przekazywaniu złośliwego kodu skryptu jako danych wejściowych i odbijaniu go do użytkownika jest po prostu nieakceptowanie kodu skryptu jako danych wejściowych. Z pewnością należy filtrować dane wejściowe z myślą o tym, ale łatwiej powiedzieć niż zrobić; sprytnie spreparowane fragmenty kodu wykonywalnego mogą prześlizgnąć się przez filtry. Jednym ze sposobów radzenia sobie z tym problemem jest zastosowanie podejścia opartego na białej liście, a nie na czarnej liście - na przykład, zamiast próbować napisać filtr, który blokuje wszystkie złośliwe kody wprowadzane do formularza internetowego, należy napisać aplikację tak, aby akceptowała dane w określonych formatach (numery telefonów, adresy e-mail itp.) tylko wtedy, gdy tego właśnie oczekujesz.
• Ucieczka danych wyjściowych. To rozwiązanie problemu z drugiej strony. Jeśli aplikacja internetowa wysyła dane wprowadzone przez użytkownika z powrotem na stronę WWW, dane te powinny być filtrowane, aby upewnić się, że nie staną się kodem wykonywalnym na tej stronie. Jeśli 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 wynikowej, a nie były zintegrowane z samym kodem HTML strony.
• Standard Content Security Policy (CSP). CSP przenosi podejście „białej listy” poza tekst wejściowy do sfery wykonywania skryptów: aplikacja internetowa powinna wykonywać tylko ten kod, który został określony przez użytkownika jako bezpieczny. Google ma kilka świetnych zasobów na temat wdrażania CSP.

Test XSS

Testowanie pod kątem podatności na ataki XSS jest ważnym aspektem zapewnienia bezpieczeństwa aplikacji internetowej. OWASP posiada zasoby, które szczegółowo opisują, w jaki sposób można testować aplikacje pod kątem podatności na ataki typu DOM lub odbite cross-site scripting. Jeśli szukasz arkusza XSS, OWASP ma dla Ciebie również dokument z kodem do ataków XSS, który może być użyty do ominięcia pewnych filtrów obronnych XSS; okaże się on bezcenny podczas testów penetracyjnych, które możesz przeprowadzić na własnych systemach.

XSS a CSRF

Możesz usłyszeć, że CSRF jest używany w tym samym kontekście co XSS. Jest to skrót od cross-site request forgery, czyli ataku, który - podobnie jak XSS - jest skierowany na przeglądarkę użytkownika. Główna różnica polega na tym, że CSRF wykorzystuje uwierzytelnioną sesję użytkownika (być może jest on zalogowany na swoje konto bankowe), podczas gdy XSS nie potrzebuje uwierzytelnionej sesji, aby być skutecznym.

Załóżmy, że użytkownik był zalogowany jednocześnie na Twitterze i w banku internetowym, i kliknął na link na Twitterze, który wyglądał tak:

http://www.yourbank.com/sendmoney,do?from=you&to=attacker&amount=5000

W zależności od tego, jak Twój bank zarządza tokenami sesji i jakiej przeglądarki używasz, możesz nagle stać się o wiele biedniejszy. XSS jest bardziej niebezpiecznym wektorem ataku, ale ważne jest, aby bronić się zarówno przed XSS, jak i CSRF. OWASP przygotował arkusz informacyjny na temat środków ochrony przed CSRF.

Niedawne i osławione ataki XSS

Jeden z najwcześniejszych i najsłynniejszych ataków typu cross-site scripting miał miejsce w 2005 roku, kiedy to przedsiębiorczy użytkownik MySpace Samy Kamkar zorientował się, że może wstawić do swojego profilu kod JavaScript, który automatycznie zaprzyjaźni się z każdym, kto odwiedzi stronę - a także skopiować ten kod do profili swoich nowych znajomych, dzięki czemu każdy, kto odwiedzi te strony, zaprzyjaźni się również z nim. (Skrypt zadbał o to, aby każdy z nowych znajomych Kamkara miał go w swojej „pierwszej ósemce”- obawiamy się, że aby to zrozumieć, trzeba było tam wtedy być, ale wierzcie nam, że było to ważne). W ciągu 24 godzin zdobył ponad milion znajomych i zmusił MySpace do krótkotrwałego wyłączenia całej witryny.

Tak zwany robak Samy okazał się w większości nieszkodliwy. Jednak inne były znacznie bardziej niepokojące:

• W serwisie Ebay przez lata występowały luki XSS, które umożliwiały hakerom kradzież danych logowania użytkowników

• Napastnicy XSS zdołali ukraść V-Bucks graczom Fortnite w 2019 r.

• Grupa hakerów Magecart zaatakowała British Airways w 2018 r. za pomocą ataku XSS, wykradając setki tysięcy tożsamości użytkowników

A samo cross-site scripting pozostaje dziś poważnym zagrożeniem. Od 2021 r. luki w zabezpieczeniach XSS znaleziono w platformie poczty elektronicznej Zimbra, Wordpress i otwartoźródłowej platformie zarządzania IT Nagios. Należy pamiętać, że hakerzy zazwyczaj nie stosują technik ataków w izolacji: cross-site scripting jest jednym z elementów złożonej i niedawno odkrytej formy ataku wykorzystującej certyfikaty TLS typu wildcard, zwanej na przykład ALPACA. Aby uniknąć poważnych zagrożeń, należy upewnić się, że luki w zabezpieczeniach XSS zostały wyeliminowane.

Źródło: CSO