Cross-site scripting (w skrócie XSS) to powszechna luka w zabezpieczeniach wielu aplikacji internetowych. Pozwala atakującemu na wstrzyknięcie złośliwy kod do witryny w taki sposób, aby przeglądarka użytkownika odwiedzającego witrynę wykonała ten kod.
Zazwyczaj, aby wykorzystać taką lukę, wymagana jest pewna interakcja z użytkownikiem: albo użytkownik zostaje zwabiony do zainfekowanej witryny za pomocą Inżynieria społeczna lub po prostu poczekaj, aż odwiedzi tę witrynę. Dlatego programiści często nie traktują poważnie luk XSS.
Ale jeśli nie zostaną wyeliminowane, może to stanowić poważne zagrożenie bezpieczeństwa.
Wyobraź sobie, że jesteśmy w panelu administracyjnym WordPressa, dodajemy Nowa treść. Jeśli użyjemy w tym celu wtyczki podatnej na XSS, może to zmusić przeglądarkę do utworzenia nowego administratora, zmodyfikowania treści i wykonania innych złośliwych działań. Cross-site scripting daje atakującemu niemal całkowitą kontrolę nad najważniejszymi oprogramowanie w dzisiejszych czasach jest to przeglądarka.
XSS: podatność na wstrzyknięcie
Każda strona internetowa lub aplikacja ma wiele punktów wprowadzania danych - od pól formularza do samego adresu URL. Najprostszym przykładem wprowadzania danych jest wpisanie nazwy użytkownika i hasła do formularza:
Nasze imię i nazwisko będzie przechowywane w bazie danych witryny w celu późniejszej interakcji z nami. Z pewnością, kiedy byłeś autoryzowany w dowolnej witrynie, zobaczyłeś osobiste powitanie w stylu „Witaj, Ilya”.
W tym celu nazwy użytkowników są przechowywane w bazie danych.
Wstrzyknięcie to procedura polegająca na wprowadzeniu specjalnego ciągu znaków zamiast nazwy lub hasła, zmuszając serwer lub przeglądarkę do odpowiedzi w określony sposób, którego potrzebuje atakujący.
Cross-site scripting to wstrzyknięcie, które wstrzykuje kod, który będzie wykonywał działania w przeglądarce w imieniu witryny. Może się to zdarzyć zarówno z powiadomieniem użytkownika, jak i w tle, bez jego wiedzy. 
Tradycyjne ataki XSS:
Odbity (nietrwały).
Odbity atak XSS jest uruchamiany, gdy użytkownik kliknie specjalnie spreparowany link.
Te luki występują, gdy dane dostarczane przez klienta internetowego, najczęściej w parametrach żądania HTTP lub Formularz HTML, są wykonywane bezpośrednio przez skrypty po stronie serwera w celu przeanalizowania i wyświetlenia strony wyników dla tego klienta, bez odpowiedniego przetwarzania.
Przechowywane (na stałe).
Przechowywany XSS jest możliwy, gdy atakującemu uda się wstrzyknąć złośliwy kod do serwera, który jest wykonywany w przeglądarce za każdym razem, gdy uzyskuje dostęp do oryginalnej strony. Klasycznym przykładem tej luki są fora umożliwiające komentarze w formacie HTML.
Luki spowodowane przez kod po stronie klienta (JavaScript, Visual Basic, Flash itp.):
Znane również jako modele DOM:
Odbity (nietrwały).
Podobnie jak w przypadku strony serwerowej, tylko w tym przypadku atak jest możliwy dzięki temu, że kod jest przetwarzany przez przeglądarkę.
Przechowywane (na stałe).
Podobnie jak XSS przechowywany po stronie serwera, tylko w tym przypadku złośliwy komponent jest przechowywany po stronie klienta przy użyciu pamięci przeglądarki.
Przykłady luk XSS.
Co ciekawe, w większości przypadków, w których opisana jest ta podatność, przeraża nas następujący kod:
http://www.site.com/page.php?var=
Istnieją dwa rodzaje luk XSS – pasywne i aktywne.
Aktywna podatność jest bardziej niebezpieczne, ponieważ atakujący nie musi zwabić ofiary specjalnym linkiem, wystarczy wstrzyknąć kod do bazy danych lub jakiś plik na serwerze. W ten sposób wszyscy odwiedzający witrynę automatycznie stają się ofiarami. Można go zintegrować np. za pomocą wstrzykiwania SQL (SQL Injection). Dlatego nie należy ufać danym przechowywanym w bazie danych, nawet jeśli zostały przetworzone podczas wstawiania.
Przykład pasywna podatność można znaleźć na samym początku artykułu. Socjotechnika jest tu już potrzebna, na przykład ważne pismo od administracji serwisu z prośbą o sprawdzenie ustawień konta po przywróceniu z kopii zapasowej. W związku z tym musisz znać adres ofiary lub po prostu zorganizować wysyłkę spamu lub post na jakimś forum, a nie jest faktem, że ofiary będą naiwne i podążą za Twoim linkiem.
Co więcej, zarówno parametry POST, jak i GET mogą być podatne na pasywną podatność. Z parametrami POST oczywiście musisz iść na sztuczki. Na przykład przekierowanie z witryny osoby atakującej.