Der Aufsatz von Martin Johns, Björn Engelmann und Joachim Posegga (PDF) beschreibt ein Erkennungssystem, das ausschließlich Zugang zum HTTP-Verkehr zwischen Webserver und Browser benötigt. So lasse es sich für jegliche Art von Webanwendungen einsetzen. Die Arbeit beschränkt sich zwar auf die Erkennung von Javascript-Schadcode, laut den Autoren lässt sich das Verfahren aber auch auf andere clientseitige Skriptsprachen wie beispielsweise VBScript anwenden.

Der XSS-Detektor benötigt lediglich Zugriff auf die HTTP-Kommunikation.

Unter Cross-Site-Scripting versteht man Angriffe, die fremde Webseiten mit verschiedenen Tricks so manipulieren, dass sie dem Browser schädlichen Skriptcode präsentieren. Häufig ist das Ziel, dem Web-Surfer Passwörter oder andere persönliche Informationen zu stehlen oder dessen Sitzung in einem geschützen Bereich zu kapern.

XSSDS kann zwei Arten von Cross-Site-Scripting (XSS) aufspüren: Zum einen Reflected XSS, eine Technik, die sich mangelnde Ein- und Ausgabeüberprüfung von Webanwendungen zunutze macht. Der Angreifer praktiziert über präparierte HTTP-Anfragen schädlichen Javascript-Code in die Ausgabeseite (die somit den Code "reflektiert"). Die andere Angriffsart heißt Stored XSS. Hier gelingt es dem Angreifer, schädliche Skripte dauerhaft in der Webanwendung zu platzieren, beispielsweise in einem Gästebuch-Eintrag. Eine dritte Art, DOM-basiertes XSS, lassen die Autoren außen vor, da es sich ausschließlich im Browser abspiele und somit serverseitig nicht zu entdecken sei.

XSSDS belauscht HTTP-Anfragen und -Antworten. Dabei prüft die Software, ob sich Teile des Skriptcodes in der Antwort bereits in der Anfrage finden. So soll sie Reflected-XSS-Angriffe aufspüren. Zum Vergleichen macht das Programm verschleiernde Kodierungen rückgängig und normalisiert beide Skripte.

Beim Cross-Site-Scripting wird der eingeschleuste Javascript-Code meist durch Kodierungen versteckt.

Mit dem Script-Tag ("<script src="http://example.org/script.js"></script>") lassen sich auch Javascript-Programme von externen Servern in eine HTML-Seite einbinden. Große Websites wie beispielsweise Ebay machen davon Gebrauch und haben eigene Skript-Hosts. Hier behilft sich XSSDS mit einer Positivliste erlaubter Hosts.

Um weitere Angriffe, insbesondere Stored XSS, zu entdecken, bedient sich der Detektor eines Verfahrens, das auch von Intrusion Detection Systemen (IDS) bekannt ist: Während einer Trainingsphase unter kontrollierten Bedingungen "lernt" das Überwachungssystem alle erlaubten Skript-Inhalte einer vertrauenswürdigen Version der Webanwendung kennen. Treten später im Betrieb andere Skripte auf, handelt es sich entweder um XSS, oder die Anwendung wurde aktualisiert. Im letzteren Fall muss der XSSDS-Admin die neuen Skripte manuell bestätigen.

Die Wissenschaftler haben gemäß diesem Konzept einen Prototypen konstruiert und seine Erfolgsrate mit einer Datenbasis von 500.000 HTTP-Request-Response-Paaren aus 95 verschiedenen Webanwendungen protokolliert. Der generische XSS-Detektor mit Trainingsdaten erreichte dabei 0 Prozent False-Negatives, es blieb ihm also kein Angriff verborgen. 20 Prozent der Anwendungen jedoch generierten ihr Javascript offenbar so unvorhersagbar dynamisch, dass diese Methode einige False-Positives, also Fehlalarme, produzierte.

Die Suche nach Skript-Fragmenten in HTTP-Anfragen, die andere Prüfmethode, glänzte nach Angaben des Aufsatzes ebenfalls mit 0 False-Negatives und schlug nur bei 5 Prozent der getesteten Anwendungen falschen Alarm.

Verwandte Verfahren finden anderswo Anwendung: Die Autoren erwähnen den XSS-Filter für Microsofts Internet Explorer 8 und die Firefox-Extension Noscript. Beides biete jedoch im Gegensatz zu XSSDS keinen Schutz gegen Stored-XSS-Angriffe.

Im Laufe der nächsten Tage soll mit NoXSS eine zumindest teilweise Umsetzung der im Aufsatz formulierten Verfahren verfügbar sein. Die Firefox-Erweiterung soll Reflected-XSS-Attacken aufspüren und wird wie der Firefox-Browser unter den drei Open-Source-Lizenzen MPL, GPL und LGPL stehen.