XSS

Atak polegający na wstrzyknięciu złośliwego skryptu na stronę, który wykona się w przeglądarce ofiary. Jedna z najczęstszych podatności aplikacji webowych.

XSS (Cross-Site Scripting) to podatność, w której atakujący wstrzykuje do strony własny kod (najczęściej JavaScript), a przeglądarka ofiary wykonuje go tak, jakby pochodził z zaufanego serwisu. Sednem problemu jest to, że dane od użytkownika trafiają do HTML-a bez odpowiedniego oczyszczenia albo kodowania, więc przeglądarka nie odróżnia treści od kodu.

Skutki bywają poważne: kradzież ciasteczek sesyjnych, podszywanie się pod zalogowanego użytkownika, podmiana zawartości strony (defacement), keylogging w formularzach czy przekierowanie na phishing. Atak działa w kontekście origin ofiary, więc skrypt ma dostęp do tego, do czego ma dostęp zalogowany użytkownik.

Trzy odmiany, które warto rozróżnić

Klasyczny podział to Stored XSS (złośliwy kod zapisuje się w bazie, np. w komentarzu, i atakuje każdego, kto wyświetli stronę), Reflected XSS (kod wraca z parametru w URL-u, ofiara musi kliknąć spreparowany link) oraz DOM-based XSS (podatność jest po stronie JavaScriptu, np. wrzucasz location.hash do innerHTML bez sanityzacji).

Przykład z praktyki

Masz pole wyszukiwarki, które wstawia frazę z powrotem na stronę. Ktoś wpisuje w URL ?q=. Jeśli wartość ląduje w HTML-u bez kodowania, skrypt wyśle ciasteczka na serwer atakującego. Do polowania na takie dziury w praktyce używasz proxy jak Burp Suite albo OWASP ZAP — przechwytujesz request, podmieniasz parametr i patrzysz, czy < wraca dosłownie, czy jako <.

Częste mity i błędy

Mit pierwszy: „mam HTTPS, więc jestem bezpieczny". HTTPS szyfruje transport, a nie chroni przed XSS — to dwie różne warstwy. Mit drugi: „wystarczy walidacja po stronie frontendu". Walidacja w przeglądarce to wygoda dla użytkownika, nie zabezpieczenie — każdy ją obejdzie. Najczęstszy błąd to czarne listy typu „wytnij słowo script" — da się je obejść setką sposobów (onerror, , kodowanie). Stawiaj na output encoding dopasowane do kontekstu (HTML, atrybut, JS, URL), Content-Security-Policy, flagę HttpOnly na ciasteczkach oraz gotowe, bezpieczne API frameworka zamiast innerHTML. Do czyszczenia HTML-a od użytkownika użyj biblioteki DOMPurify, nie własnego regexa.

Pojęcia powiązane

OWASP Top 10, CSRF, Content-Security-Policy, sanityzacja danych, output encoding, same-origin policy, SQL Injection (pokrewna klasa wstrzyknięć), HttpOnly i SameSite w ciasteczkach.