XSS (Cross-Site Scripting)

XSS (Cross-Site Scripting) to podatność, w której aplikacja nie neutralizuje albo błędnie neutralizuje danych kontrolowanych przez użytkownika, zanim umieści je na stronie podawanej innym użytkownikom ^[1]. Efektem jest skrypt atakującego wykonywany w przeglądarce ofiary tak, jakby pochodził z zaufanej witryny. OWASP zalicza XSS do ataków typu wstrzyknięcie, w których złośliwe skrypty trafiają do skądinąd nieszkodliwych i zaufanych serwisów ^[2]. W zestawieniu CWE Top 25 za 2024 rok słabość CWE-79 zajęła pierwsze miejsce ^[3].

Jak działa

Według OWASP podatność XSS powstaje, gdy spełnione są dwa warunki: dane trafiają do aplikacji z niezaufanego źródła, najczęściej z żądania HTTP, i zostają dołączone do treści dynamicznej wysyłanej użytkownikowi bez sprawdzenia ^[2]. Przeglądarka nie odróżnia wtedy kodu strony od kodu wstrzykniętego. Skrypt działa z uprawnieniami witryny: widzi jej treść, może wysyłać żądania w imieniu zalogowanego użytkownika i czytać ciasteczka, które nie mają flagi HttpOnly.

Przebieg typowego ataku przez złośliwy link pokazuje schemat poniżej.

RYS. 1Reflected XSS przez link

Mechanizm widać na prostym przykładzie w PHP. Pierwsza linia wypisuje parametr wprost, druga koduje go dla kontekstu HTML.

echo 'Wyniki dla: ' . $_GET['q'];            // podatne
echo 'Wyniki dla: ' . esc_html( $_GET['q'] ); // zakodowane

Odmiany

MITRE wyróżnia trzy główne typy XSS ^[1]. Różnią się tym, gdzie ładunek jest przechowywany i kto składa go w stronę.

Stored XSS jest zwykle groźniejszy od odbitego, bo nie wymaga namawiania ofiary do kliknięcia. Wystarczy, że administrator otworzy w panelu komentarz albo wpis z ładunkiem.

W WordPressie

W WordPressie większość błędów XSS dotyczy wtyczek i motywów, które wypisują dane bez kodowania; zob. podatność we wtyczce i podatność w motywie. Rdzeń udostępnia funkcje do obu stron obrony.

Kodowanie wyjścia. Dokumentacja WordPressa definiuje escapowanie jako zabezpieczanie danych wyjściowych przez usuwanie niechcianych elementów, takich jak zniekształcony HTML albo znaczniki skryptów ^[4]. Zaleca zasadę „escape late”: kodować jak najbliżej miejsca wypisania, bo to ułatwia przegląd kodu i automatyczne skanowanie ^[4]. Funkcja dobierana jest do kontekstu.

Czyszczenie wejścia. Sanityzacja to według dokumentacji zabezpieczanie, czyszczenie i filtrowanie danych wejściowych ^[5]. Walidacja jest preferowana, bo jest bardziej precyzyjna; sanityzacja jest następnym wyborem, gdy walidacja nie jest możliwa ^[5]. Przykładowo sanitize_text_field() sprawdza poprawność UTF-8 i usuwa wszystkie znaczniki ^[5].

Uprawnienie unfiltered_html. Uprawnienie unfiltered_html pozwala publikować znaczniki HTML, a nawet kod JavaScript we wpisach, stronach, komentarzach i widżetach ^[6]. Na pojedynczej witrynie mają je administrator i redaktor, a w sieci Multisite tylko superadministrator ^[6]. Dokumentacja ostrzega, że nadanie go niezaufanym użytkownikom może skończyć się publikacją złośliwego kodu ^[6]. Dlatego ważne są role i uprawnienia użytkowników: autor i współpracownik tego uprawnienia nie mają ^[6], więc wstawiany przez nich HTML powinien przejść przez filtr.

Zagrożenia i skutki

MITRE wymienia jako skutki XSS ujawnienie informacji z ciasteczek i danych sesji, kradzież lub manipulację ciasteczkami, a w połączeniu z innymi błędami wykonanie dowolnego kodu ^[1]. OWASP dodaje przejęcie sesji, nieuprawniony dostęp do kont, podmianę treści strony, instalację złośliwego oprogramowania i przekierowania na strony atakującego ^[2].

• Przejęcie sesji i przejęcie konta przez kradzież tokenu sesyjnego.
• Działania w panelu w imieniu administratora, na przykład utworzenie nieautoryzowanego konta administratora.
• Podmiana treści strony i złośliwe przekierowania.
• web skimming, czyli podsłuch formularzy płatności w sklepie.

Jak się bronić

Podstawą jest kodowanie danych przy wyjściu, dopasowane do kontekstu, i walidacja przy wejściu. MITRE zaleca sprawdzone biblioteki i frameworki, kodowanie wyjścia, walidację wejścia z listą dozwolonych wartości oraz flagę HttpOnly na ciasteczkach sesji ^[1]. Jako obronę warstwową wymienia też zapory aplikacyjne ^[1], czyli WAF.

Drugą warstwą jest CSP (Content Security Policy). MDN opisuje Content Security Policy jako zestaw instrukcji od witryny do przeglądarki, ograniczających to, co kod strony może robić, używany głównie przeciw XSS ^[7]. Jeśli polityka zawiera dyrektywę default-src albo script-src, skrypty w linii nie wykonają się bez dodatkowego oznaczenia, na przykład jednorazowego nonce albo skrótu ^[7]. MDN zaznacza, że CSP nie zastępuje czyszczenia danych wejściowych: strona powinna robić jedno i drugie ^[7]. CSP należy do szerszej grupy nagłówków bezpieczeństwa HTTP.

Historia i przykłady

Błędy XSS występują także w oprogramowaniu używanym w Polsce. CERT Polska 2 czerwca 2026 roku opublikował informację o podatnościach w systemie Wirtualna Uczelnia firmy Simple SA; jedna z nich, CVE-2026-34907, to Reflected Cross-Site Scripting w parametrze locale w kilku punktach końcowych ^[8]. Ta sama publikacja opisuje CVE-2026-34906, wstrzyknięcie szablonu po stronie serwera prowadzące do zdalnego wykonania kodu ^[8]. Wersje późniejsze niż wskazana w komunikacie kompilacja z 27 marca 2026 roku nie są już podatne ^[8].