Web-Anwendungen sind häufig in Skriptsprachen wie PHP oder Perl programmiert, um dynamische Inhalte zu ermöglichen. Dabei werden die Benutzereingaben oft in den GET-Parametern der URL kodiert. Werden diese Parameter nun ohne eine vorherige Prüfung im Programm weiterverarbeitet, so kann man in diesen Parametern Programmcode unterbringen, der dann in der erzeugten Webseite auftaucht. Typischerweise nimmt man da JavaScript, da dies in den meisten Browsern aktiviert hat. Theoretisch könnte man auch Programmcode in anderen Programmiersprachen einschleusen, in den folgenden Beispielen beschränke ich mich jedoch auf JavaScript.
Wird nun der Inhalt einer Variable, die über einen GET-Parameter an das Skript übergeben wurde, ungefiltert ausgegeben, so landet der darin eingebettete JavaScript-Code in der Webseite und wird vom Browser ausgeführt. Da das lokal ausgeführte JavaScript Zugriff auf die vom Browser verwalteten Cookies hat, kann der Inhalt der Cookies ausgelesen werden und z.B. an eine andere Webseite geschickt werden. Viele Web-Anwendungen speichern ihre Authentifikationsdaten in solchen Cookies, so dass ein Angreifer sich damit Zugang zu einer fremden Identität erschleichen kann. Er muss sein Opfer nur dazu bringen, auf die speziell präparierte URL zu klicken. Diese URLs können aber auch in Image-Tags untergebracht werden, wo sie dann automatisch beim Laden der Webseite ``ausgeführt'' werden.
Häufige Angriffsziele dieser Art von XSS sind Foren, Gästebücher, Suchformulare, Webmailer und sogar dynamisch generierte Fehler-404-Seiten.
Geeignete Schutzmaßnahmen sind die Überprüfung sämtlicher Benutzereingaben. Dies schließt neben den HTTP GET- und POST-Variablen auch die Cookies ein, die ja auch vom Client an den Server übermittelt werden. Bei der Überprüfung sollten alle nicht akzeptablen Werte, die nicht innerhalb eines fest definierten Wertebereichs liegen, herausgefiltert werden. Sonderzeichen, die vom Browser besonders interpretiert werden (wie etwa die spitzen Klammern < und >), müssen vor der Ausgabe in ihre HTML-Entities konvertiert werden.
Diese Schutzmaßnahmen sind einfach zu implementieren. Da sie jedoch mit zeitlichem Aufwand verbunden sind und nichts zur Funktionalität der Anwendung beitragen, werden sie gerne vergessen, was nicht zuletzt auch Grund für die weite Verbreitung dieser Sicherheitslücken ist.