Bezpieczeństwo

XSS

2000AktywnyOpublikowano: 29 września 2026Aktualizacja: 29 września 2026Opublikowany

Podatność aplikacji webowych, w której atakujący wstrzykuje złośliwy skrypt (zwykle JavaScript) wykonywany w przeglądarce ofiary w zaufanym kontekście witryny.

Kluczowa innowacja

Uświadomił, że zaufanie przeglądarki do treści serwowanej przez witrynę można wykorzystać, wstrzykując wykonywalny skrypt przez niewalidowane lub niekodowane dane wejściowe, i ustanowił kodowanie wyjścia zależne od kontekstu jako podstawową obronę.

Kategoria

Bezpieczeństwo

Poziom abstrakcji

Wzorzec

Poziom operacji

AplikacjaSystemŚrodowisko agentowe

Zastosowania

Przejęcie sesji przez kradzież ciasteczek/tokenówKradzież danych uwierzytelniających (phishing w origin)Podmiana i defacement treści stronyDystrybucja malware i drive-by downloadKeylogging i przechwytywanie danych z formularzyPrompt injection prowadzący do XSS w interfejsach LLMXSS w kodzie HTML/JS generowanym przez modele AIRenderowanie niezaufanych treści przez agentów AI

Jak działa

1) Atakujący identyfikuje punkt wejścia, gdzie dane sterowane przez użytkownika (parametr URL, pole formularza, nagłówek, zawartość bazy danych) są umieszczane w odpowiedzi bez neutralizacji. 2) Konstruuje ładunek zawierający znaczniki lub kod skryptu (np. <script>, atrybut zdarzenia onerror, javascript: URI). 3) Ładunek jest dostarczany: w Reflected XSS przez spreparowany link lub żądanie, którego skrypt jest natychmiast odbijany w odpowiedzi; w Stored XSS przez trwałe zapisanie ładunku na serwerze (komentarz, wpis forum, log), skąd trafia do kolejnych odwiedzających; w DOM-based XSS przez kod JavaScript po stronie klienta, który zapisuje niezaufane dane do niebezpiecznego 'sink' (np. innerHTML) bez opuszczania przeglądarki. 4) Przeglądarka ofiary wykonuje skrypt w origin zaufanej witryny, uzyskując dostęp do ciasteczek, tokenów sesji i DOM, co umożliwia przejęcie sesji, kradzież danych, keylogging lub dalsze żądania w imieniu ofiary.

Rozwiązany problem

Porządkuje i nazywa klasę podatności, w której niezaufane dane wejściowe trafiają do kontekstu wykonywalnego przeglądarki (HTML, atrybuty, JavaScript, CSS, URL) bez właściwego kodowania lub sanityzacji. Zrozumienie XSS pozwala projektować obronę: kodowanie wyjścia zależne od kontekstu, sanityzację HTML i Content Security Policy, dzięki którym dane pozostają danymi, a nie kodem.

Komponenty

Reflected XSS (Type-I)Wariant nieutrwalony

Wstrzyknięty skrypt jest natychmiast odbijany przez serwer w odpowiedzi (np. komunikat błędu, wynik wyszukiwania) i wykonywany, gdy ofiara otworzy spreparowany link lub żądanie. Nazywany też nieutrwalonym lub Type-I XSS.

Stored XSS (Type-II)Wariant utrwalony

Złośliwy skrypt jest trwale zapisany na serwerze docelowym (baza danych, forum, log odwiedzin, pole komentarza) i serwowany kolejnym użytkownikom. Nazywany też utrwalonym lub Type-II XSS. Wariant Blind XSS to Stored XSS, którego ładunek wykonuje się później, gdy treść otworzy np. administrator zaplecza.

DOM-based XSSWariant po stronie klienta

Podatność po stronie klienta, zidentyfikowana w 2005 roku, występująca gdy JavaScript manipuluje DOM przy użyciu niezaufanych danych, zapisując je do niebezpiecznego 'sink' (np. innerHTML, document.write, eval) bez udziału serwera.

Implementacja

Implementacje referencyjne

DOMPurify

JavaScript · Cure53 (biblioteka sanityzacji HTML — obrona przed XSS)

OWASP Java Encoder

Java · OWASP (kodowanie wyjścia zależne od kontekstu)

Pułapki implementacyjne

Zapis niezaufanych danych do niebezpiecznych 'sinków'Krytyczna

Użycie innerHTML, document.write, eval lub odpowiedników frameworkowych (React dangerouslySetInnerHTML, Angular bypassSecurityTrustAs*, Lit unsafeHTML) do wstawiania danych sterowanych przez użytkownika omija wbudowane zabezpieczenia i prowadzi do DOM-based XSS.

Rozwiązanie:Preferuj bezpieczne 'sinki' traktujące wejście jako tekst: .textContent, .setAttribute(), .value, .insertAdjacentText(). Dla treści HTML autorstwa użytkownika użyj sanityzatora (np. DOMPurify) i regularnie go aktualizuj.

Brak kodowania wyjścia zależnego od kontekstuWysoka

Umieszczanie danych bez kodowania właściwego dla kontekstu (HTML, atrybut, JavaScript, CSS, URL) pozwala na wyjście z kontekstu danych. Kodowanie HTML nie chroni wewnątrz <script>, komentarzy HTML, bloków <style> ani atrybutów zdarzeń.

Rozwiązanie:Stosuj kodowanie zależne od kontekstu: HTML entity encoding w treści HTML, kodowanie atrybutów, \uXXXX w wartościach JavaScript, \XX w CSS, percent-encoding w URL. Nigdy nie umieszczaj zmiennych bezpośrednio w kontekstach wykonywalnych.

Poleganie na filtrowaniu wejścia typu blacklistWysoka

Próby blokowania XSS przez czarne listy słów/znaków są łatwe do obejścia (kodowanie, alternatywne wektory, nowe elementy HTML) i dają fałszywe poczucie bezpieczeństwa.

Rozwiązanie:Traktuj walidację wejścia jako obronę pomocniczą (allowlist), a nie podstawową. Podstawą jest kodowanie wyjścia i sanityzacja HTML w miejscu użycia danych.

Traktowanie CSP jako jedynej ochronyŚrednia

Content Security Policy bywa błędnie traktowane jako podstawowa obrona; źle skonfigurowane lub zbyt liberalne polityki (np. unsafe-inline) nie powstrzymają XSS, a jednolite polityki korporacyjne mogą psuć starsze systemy.

Rozwiązanie:Używaj CSP jako defense-in-depth (nonces/hashes, brak unsafe-inline), dopasowanej do aplikacji, a nie jako zamiennika kodowania wyjścia i sanityzacji.

Ewolucja

Oryginalny paper · 2000 · CERT Coordination Center (CERT/CC)

CERT Advisory CA-2000-02: Malicious HTML Tags Embedded in Client Web Requests

2000

Ukucie terminu i pierwszy alert CERT

Punkt przełomowy

Inżynierowie bezpieczeństwa Microsoftu ukuli termin 'cross-site scripting'; CERT/CC opublikował advisory CA-2000-02 opisujące wstrzykiwanie złośliwych znaczników HTML w żądaniach webowych.

2005

Zdefiniowanie DOM-based XSS

Punkt przełomowy

Opisano DOM-based XSS jako odrębny, po stronie klienta wariant podatności, w którym ładunek nigdy nie opuszcza przeglądarki.

2013

XSS jako A3 w OWASP Top 10

W zestawieniu OWASP Top 10 (2013) Cross-Site Scripting sklasyfikowano jako osobną kategorię ryzyka A3.

2021

Włączenie XSS do kategorii Injection

W OWASP Top 10 (2021) Cross-Site Scripting zostało włączone do szerszej kategorii A03:2021 – Injection.