XSS (Cross-Site Scripting)
XSS (cross-site scripting) to klasa luk w aplikacjach webowych, w której przeglądarka ofiary wykonuje skrypt dostarczony przez napastnika, ale w kontekście zaufanej domeny. Strona wygląda jak zwykle. Kod działa z uprawnieniami tej strony wobec cookie, DOM i lokalnego storage.
Na blackweb.pl XSS nie jest ćwiczeniem z alert(). Jest mechanizmem, który łączy się z kradzieżą session cookie, z phishingiem wewnątrz prawdziwej domeny i z social engineering w przeglądarce, której użytkownik ufa.
Co się dzieje (opisowo)
Aplikacja bierze dane z użytkownika albo z URL i wstawia je do HTML bez poprawnej izolacji. Komentarz, pole wyszukiwania, parametr przekierowania, błąd walidacji wyświetlony „jak jest”. Przeglądarka traktuje wstrzyknięty fragment jak część strony. Stąd nazwa: skrypt „z innej strony” ląduje w kontekście Twojej.
Tradycyjnie mówi się o typach reflected (payload w żądaniu, od razu w odpowiedzi), stored (payload zapisany i serwowany innym) oraz DOM-based (logika po stronie klienta skleja niezaufane dane w niebezpieczne API). Podział pomaga w raportach i w bug bounty. Nie zmienia faktu, że skutek dla ofiary bywa ten sam: kod w zaufanym kontekście.
Co jest stawką
Najczęstszy cel w praktyce to sesja. Skrypt czyta cookie (jeśli nie ma flagi HttpOnly) albo korzysta z innych tokenów dostępnych w DOM i wysyła je na zewnątrz. Potem napastnik wczytuje sesję u siebie. 2FA przy logowaniu już nie pomaga, bo sesja jest po uwierzytelnieniu. Patrz też stealerzy: XSS to nie jedyna droga do cookie, ale historycznie jedna z klasycznych.
Inne skutki: fałszywy formularz na prawdziwej domenie, przekierowanie, defacement, nadużycie funkcji „zalogowany użytkownik może X”. XSS bywa też ogniwem w łańcuchu, nie celem samym w sobie.
Obrona (strona serwisu, nie checklista ataku)
Po stronie aplikacji: kontekstowe escapowanie wyjścia, Content Security Policy, HttpOnly i Secure na cookie sesyjnych, unikanie niebezpiecznych sinków w JS, walidacja wejścia jako warstwa dodatkowa, nie jedyna. Frameworki pomagają, gdy się ich nie obchodzi. Gdy się obchodzi (np. dangerouslySetInnerHTML bez filtra), wracasz do punktu wyjścia.
Po stronie użytkownika XSS rzadko da się „naprawić” ustawieniem. Da się ograniczyć ekspozycję: krótsze sesje, wylogowanie, świadomość, że zaufana domena nie gwarantuje zaufanej treści, jeśli ktoś wstrzyknął skrypt. To łączy się z opsec i higieną stacji przy infostealerach.
Czego tu nie ma
Nie ma gotowca payloadów ani mapy pól do testowania cudzych serwisów. Jest definicja i stawka, bo bez tego raporty o „XSS w panelu” brzmią jak żargon bez konsekwencji.