XSStrike Tutorial: XSS-Scanner installieren & nutzen (2026)

XSStrike gilt als einer der fortschrittlichsten Open-Source-Scanner für Cross-Site-Scripting (XSS). Statt stumpf eine Payload-Liste durchzuprobieren, analysiert das Tool zunächst den Reflexionskontext der Serverantwort mit vier handgeschriebenen Parsern und generiert erst danach einen Payload, der in genau diesem Kontext funktionieren soll. Dieses XSStrike Tutorial zeigt Ihnen Schritt für Schritt, wie Sie den XSS-Scanner 2026 korrekt installieren und einsetzen.

Das Besondere an diesem Tutorial: Jeder genannte Befehl wurde gegen den echten Quellcode von XSStrike geprüft. In vielen Anleitungen, auch in einigen der meistgelesenen deutschen Quellen, kursiert ein Flag namens --params, das im aktuellen Code gar nicht existiert. Ebenso taucht ein angebliches -o-Flag zum Speichern von Ergebnissen auf, das es ebenfalls nicht gibt. Wir arbeiten ausschließlich mit Optionen, die tatsächlich funktionieren, und benennen die Grenzen des Tools ehrlich.

Dieser Artikel setzt voraus, dass Sie die Grundlagen von XSS (reflektiert, gespeichert, DOM-basiert) bereits kennen. Falls nicht, lesen Sie zuerst unseren Grundlagenartikel zu Cross-Site-Scripting, hier konzentrieren wir uns auf die praktische Arbeit mit dem Werkzeug.

Was ist XSStrike und für wen ist es gedacht

XSStrike (Repository: github.com/s0md3v/XSStrike, Autor s0md3v, GPL-3.0) beschreibt sich selbst als "Cross Site Scripting detection suite equipped with four hand written parsers, an intelligent payload generator, a powerful fuzzing engine and an incredibly fast crawler". Der entscheidende Unterschied zu simplen Scannern: XSStrike führt eine Kontextanalyse durch. Es versteht, ob Ihre Eingabe im HTML-Text, in einem Attribut, in einem <script>-Block oder in einem Event-Handler landet, und passt den Payload entsprechend an. Cross-Site-Scripting zählt zu den klassischen Angriffsklassen der OWASP Top 10, entsprechend wichtig ist ein zuverlässiger Scanner dafür.

Intern setzt das Tool auf drei weitere Projekte desselben Autors: Photon als Crawler, Zetanize als HTML-Parser und Arjun für die Parameter-Erkennung. Die Kernfunktionen laut README:

• Scannen von reflektiertem und DOM-basiertem XSS
• Multithreaded Crawling
• Kontextanalyse und intelligente Payload-Generierung
• WAF-Erkennung und -Umgehung (Evasion)
• Fuzzing-Engine zum Testen von Filtern
• Blind-XSS-Unterstützung
• Bruteforce von Payloads aus einer Datei
• Payload-Encoding
• Scan auf veraltete JavaScript-Bibliotheken

Wichtige Einschränkung: nur reflektiertes XSS zuverlässig

Auch wenn das README "Reflected and DOM XSS scanning" verspricht, sollten Sie eine Grenze kennen, die in kaum einem Tutorial steht: In der Praxis ist XSStrike vor allem ein Werkzeug für reflektiertes XSS. Die Bug-Bounty-Plattform HackerOne ordnet XSStrike ausdrücklich als Tool ein, das "only supports reflected" XSS, im Gegensatz zu Dalfox, das auch gespeichertes (Stored) XSS abdeckt. Gespeicherte XSS-Lücken, bei denen der Payload dauerhaft in einer Datenbank landet und an anderer Stelle ausgeliefert wird, findet ein automatisierter Query-Scanner naturgemäß nur schwer.

Hinzu kommt: Laut Changelog wurde in Version 3.1.3 die "browser engine emulation" entfernt. Die frühere Validierung von DOM-Funden über eine echte Browser-Engine gibt es also nicht mehr. Behandeln Sie DOM-Treffer daher als Hinweise, die Sie manuell im Browser verifizieren müssen, nicht als bewiesene Schwachstellen.

Ist XSStrike 2026 noch aktuell? Ein ehrlicher Wartungsstatus

Viele Tutorials verschweigen, wie es um die Pflege des Projekts steht. Der Stand (Prüfung über die GitHub-API am 12. Juli 2026):

• Das Repository ist nicht archiviert und trägt keinen "no longer maintained"-Hinweis.
• Der letzte Code-Push des Maintainers stammt vom 26. April 2025, liegt also über ein Jahr zurück.
• Die letzte offizielle Release ist 3.1.6 vom 17. März 2025.
• Das Projekt zählt rund 15.000 Sterne und über 2.000 Forks bei etwa 92 offenen Issues.
• Die Community ist weiterhin aktiv: 2026 stehen mehrere offene Pull Requests im Raum, darunter eine Test-Suite mit CI/CD (PR #444, Juni 2026) und Fehlerbehebungen (PR #443, PR #439). Gemergt wurden sie bislang nicht.

Die ehrliche Einordnung lautet also: XSStrike ist nicht tot, aber der ursprüngliche Maintainer pusht seit über einem Jahr keinen Code mehr. Weiterentwicklung kommt aktuell fast ausschließlich aus offenen Community-PRs. Roadmap-Punkte aus der FAQ wie ein Burp-Suite-Plugin oder eine Browser-Erweiterung wurden nie fertig veröffentlicht. Für ein Tutorial 2026 heißt das: Das Tool funktioniert und ist stabil, Sie sollten aber nicht auf baldige neue Features hoffen.

Voraussetzungen

XSStrike ist ein Python-3-Werkzeug. Der Quellcode bricht bei Python 2 explizit mit der Meldung "Use python > 3.4 to run XSStrike" ab. In der Praxis empfiehlt sich Python 3.7 oder neuer. Es werden nur drei externe Pakete benötigt, die in der requirements.txt stehen:

• tld
• fuzzywuzzy
• requests

Getestet ist das Tool laut Wiki auf Linux, Termux, Windows und macOS. Beachten Sie: Die farbige Konsolenausgabe funktioniert unter Windows und macOS nicht zuverlässig, unter Linux dagegen schon.

Installation: drei Wege im Detail

Weg 1: git clone plus pip (offizieller Weg)

Der im README dokumentierte Standardweg:

git clone https://github.com/s0md3v/XSStrike
cd XSStrike
pip install -r requirements.txt --break-system-packages

Danach starten Sie das Tool mit:

python xsstrike.py

Ein Hinweis zum Aufruf: Auf aktuellen Debian-, Ubuntu- und Kali-Systemen gibt es außerhalb einer virtuellen Umgebung oft keinen python-Alias, sondern nur python3. Nutzen Sie dann python3 xsstrike.py. Innerhalb der weiter unten beschriebenen venv funktioniert python dagegen zuverlässig.

Das Flag --break-system-packages ist neu im offiziellen README und der häufigste Stolperstein. Auf modernen Debian-, Ubuntu- und Kali-Systemen ist die System-Python-Installation nach PEP 668 als "externally managed" markiert. Ohne dieses Flag bricht pip install mit der Fehlermeldung error: externally-managed-environment ab. Das Flag erlaubt die Installation trotzdem, greift aber in die systemweite Python-Umgebung ein.

Weg 2: virtuelle Umgebung (empfohlen)

Sauberer und ohne Eingriff ins System-Python ist eine virtuelle Umgebung. Das ist der Weg, den wir für die meisten Nutzer empfehlen:

git clone https://github.com/s0md3v/XSStrike
cd XSStrike
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
python xsstrike.py -h

Innerhalb der aktivierten Umgebung brauchen Sie --break-system-packages nicht, weil pip in ein isoliertes Verzeichnis statt in die Systemumgebung schreibt.

Weg 3: apt install auf Kali Linux

Wenig bekannt: XSStrike liegt als fertiges Kali-Paket vor. Wichtig zu wissen, es ist auf Kali nicht standardmäßig vorinstalliert (anders als Nmap, Nikto oder SQLMap), Sie müssen es selbst installieren:

sudo apt install xsstrike

Das Kali-Paket entspricht Version 3.1.6 und zieht die Abhängigkeiten python3-tld, python3-fuzzywuzzy und python3-requests mit. Der Paketweg ist bequem, kann aber eine gepinnte, etwas ältere Version installieren als der aktuelle master-Branch von GitHub.

Optionale Zusatzpakete gegen Warnungen

Manche Anleitungen empfehlen zwei zusätzliche Pakete, die nicht in der requirements.txt stehen:

pip install python-Levenshtein prettytable

fuzzywuzzy empfiehlt intern python-Levenshtein für bessere Performance, sonst erscheint eine Warnung und das Tool fällt auf eine langsamere reine Python-Implementierung zurück. prettytable verbessert die Tabellenausgabe. Beide sind optional, kein Pflichtschritt.

Sonderfall Termux (Android)

Für mobiles Testen unter Termux ist ein zusätzlicher Schritt nötig, den kein Desktop-Tutorial nennt. Neuere urllib3-Versionen (2.x) verursachen dort Kompatibilitätsprobleme:

pkg update && pkg upgrade && pkg install git python -y
git clone https://github.com/s0md3v/XSStrike.git
cd XSStrike
pip install -r requirements.txt
pip uninstall -y urllib3 && pip install "urllib3<2"
python xsstrike.py -h

Der urllib3<2-Downgrade in der vorletzten Zeile ist der kritische Schritt. Falls Sie auch auf einem Desktop ähnliche SSL- oder Verbindungsfehler sehen, kann dieser Downgrade dort ebenfalls helfen.

Alle XSStrike-Befehle und CLI-Flags im Überblick (gegen den Quellcode geprüft)

Die folgende Tabelle listet die Optionen, die tatsächlich in der argparse-Definition von xsstrike.py (Stand Push vom 26. April 2025) existieren. --params und -o sind hier bewusst nicht enthalten, weil sie im Code fehlen.

Ein wichtiger Hinweis zu den Standardwerten: Ältere Tutorials nennen oft "2 Threads, 7 Sekunden Timeout". Der aktuelle Quellcode (core/config.py) setzt aber threadCount = 10, timeout = 10 und delay = 0. Verlassen Sie sich im Zweifel auf den Code, nicht auf ältere Wiki-Angaben.

Der falsche --fuzz-Fehler

Eine sehr verbreitete Falschangabe (auch in den bisherigen Fassungen dieses Artikels) ist das Flag --fuzz. Das korrekte Flag heißt --fuzzer. Der Name fuzz ist lediglich die interne argparse-Zielvariable (dest='fuzz'), nicht die Kommandozeilenoption. Auf der Kommandozeile funktioniert nur --fuzzer.

Praxis-Workflows Schritt für Schritt

XSStrike entscheidet anhand der gesetzten Flags, in welchen Modus es geht. Vereinfacht gilt: --fuzzer startet den Fuzzing-Modus, -f/--file startet den Bruteforce-Modus, --crawl oder --seeds starten den Crawler, und ohne diese Flags läuft der normale Einzel-URL-Scan.

> Rechtlicher Hinweis vorab: Führen Sie die folgenden Befehle ausschließlich gegen Systeme aus, für die Sie eine ausdrückliche Erlaubnis haben, oder gegen die weiter unten genannten legalen Übungsziele. Mehr dazu im Abschnitt "Rechtlicher Rahmen".

Workflow 1: reflektiertes XSS auf einer einzelnen URL finden

Der Einstiegsbefehl. Sie übergeben eine URL mit einem Query-Parameter, den XSStrike testen soll:

python xsstrike.py -u "http://testphp.vulnweb.com/listproducts.php?cat=1"

XSStrike prüft zunächst auf DOM-Schwachstellen, erkennt eine eventuell vorgeschaltete WAF, testet dann jeden Parameter auf Reflexionen und generiert bei einem Treffer kontextbezogene Payloads. Eine typische Ausgabe bei einem Fund sieht so aus (illustrativ):

        XSStrike v3.1.6

[~] Checking for DOM vulnerabilities
[+] WAF Status: Offline
[!] Testing parameter: cat
[!] Reflections found: 1
[~] Analysing reflections
[~] Generating payloads
[!] Payloads generated: 3072
------------------------------------------------------------
[+] Payload: <a%0aonmouseover=confirm()>v3dm0s
[!] Efficiency: 100
[!] Confidence: 10
------------------------------------------------------------

Die Zeichenkette v3dm0s ist kein Zufall: Sie steht in core/config.py als xsschecker und dient XSStrike als harmloser Marker, um Reflexionen zu erkennen. Efficiency gibt an, wie gut der Payload den Kontext umgeht (Payloads unter minEfficiency = 90 werden gar nicht erst angezeigt), Confidence ist die Trefferwahrscheinlichkeit.

Workflow 2: DOM-Prüfung überspringen (Scans beschleunigen)

Bei reinen reflektierten Tests können Sie die DOM-Analyse abschalten, das spart Zeit:

python xsstrike.py -u "http://testphp.vulnweb.com/listproducts.php?cat=1" --skip-dom

Workflow 3: POST-Anfragen und JSON-Daten testen

Viele verwundbare Endpunkte nehmen POST-Daten entgegen. Übergeben Sie diese mit --data:

python xsstrike.py -u "http://beispiel.local/search.php" --data "q=query"

Verarbeitet die Anwendung JSON, ergänzen Sie --json, damit XSStrike den Body korrekt als JSON behandelt:

python xsstrike.py -u "http://beispiel.local/api/search" --data '{"q":"query"}' --json

Workflow 4: Injektion in den URL-Pfad

Bei URL-Rewriting steckt die Nutzereingabe im Pfad statt in einem Query-Parameter. Dafür gibt es --path:

python xsstrike.py -u "http://beispiel.local/search/query" --path

Workflow 5: eine ganze Domain crawlen

Statt jede URL einzeln anzugeben, lässt XSStrike den Photon-Crawler los. Er sammelt Formulare und Parameter automatisch. Mit -l steuern Sie die Crawling-Tiefe, mit -t die Parallelität:

python xsstrike.py -u "http://testphp.vulnweb.com/" --crawl -l 3 -t 10

Alternativ laden Sie eine Liste von Start-URLs aus einer Datei:

python xsstrike.py --seeds urls.txt --crawl

Ein Wort der Vorsicht: XSStrike arbeitet sehr schnell. Bei großen Zielen erzeugt ein hoher Thread-Wert eine erhebliche Last. Setzen Sie in solchen Fällen ein Delay und reduzieren Sie die Threads.

Workflow 6: Fuzzing und WAF-Analyse

Der --fuzzer-Modus schickt eine eingebaute Liste von Fuzz-Strings gegen einen Parameter, um zu sehen, welche Zeichen und Tags eine Web Application Firewall durchlässt oder blockt. Das ist die Grundlage für gezielte WAF-Umgehung:

python xsstrike.py -u "http://beispiel.local/search.php?q=query" --fuzzer -d 1

Das -d 1 (ein Sekunde Delay) ist beim Fuzzing sinnvoll, um nicht in ein Rate-Limit zu laufen. XSStrike testet dann Strings wie <test, <test>, <test x=y oder <test/oNxX=yYy// und zeigt für jeden an, ob er gefiltert, teilweise gefiltert oder unverändert reflektiert wird.

Workflow 7: eigene Payloads per Bruteforce

Haben Sie eine eigene Payload-Liste, laden Sie sie mit -f. XSStrike wechselt dann in den Bruteforce-Modus und probiert Ihre Payloads durch, ohne eigene zu generieren:

python xsstrike.py -u "http://beispiel.local/search.php?q=query" -f payloads.txt

Workflow 8: Blind XSS

Blind XSS wird nicht sofort sichtbar, sondern erst später ausgeführt, etwa im Admin-Backend. XSStrike injiziert dafür beim Crawlen einen von Ihnen definierten Callback-Payload in jedes gefundene Formular. Wichtig: Der Payload wird nicht per Flag übergeben, sondern muss vorher in core/config.py in die Variable blindPayload eingetragen werden (standardmäßig leer). Als Callback-Dienst eignet sich zum Beispiel eine selbstgehostete xsshunter-Instanz.

python xsstrike.py -u "http://beispiel.local/contact.php" --crawl --blind

Blind-XSS-Injektion funktioniert nur im Crawling-Modus, nicht beim einfachen Einzel-URL-Scan.

Weitere nützliche Optionen

HTTP-Header oder Cookies mitgeben (etwa für authentifizierte Bereiche):

python xsstrike.py -u "http://beispiel.local/faq.php?lang=q" --headers "Cookie: session=abc123"

Payloads kodieren, um simple Filter zu umgehen:

python xsstrike.py -u "http://beispiel.local/faq.php?lang=q" -e base64

Über einen Proxy laufen (etwa Burp auf 0.0.0.0:8080), um den Verkehr mitzuschneiden:

python xsstrike.py -u "http://beispiel.local/faq.php?lang=q" --proxy

Nach Updates suchen:

python xsstrike.py --update

Den Fund verifizieren

Ein Scanner-Treffer ist noch kein Beweis. Kopieren Sie den von XSStrike ausgegebenen Payload in die entsprechende URL oder das Formularfeld und öffnen Sie das Ergebnis im Browser. Führt der Browser das Skript aus (etwa ein confirm()-Popup), ist die Schwachstelle bestätigt. Gerade bei DOM-Treffern ist dieser manuelle Schritt Pflicht, weil XSStrike seit Version 3.1.3 keine Browser-Engine zur Validierung mehr nutzt und daher False Positives melden kann.

Die methodische Grundlage dahinter beschreibt der OWASP Web Security Testing Guide (WSTG-INPV-01) in drei Phasen: Eingabevektoren identifizieren, Testdaten einspeisen, resultierendes HTML auf ungefilterte Sonderzeichen (<, >, &, ', ") prüfen. XSStrike automatisiert genau diese Schritte, ersetzt aber nicht das manuelle Nachdenken.

Was tun nach dem Fund? Kurz zur Behebung

Wenn Sie eine Lücke in eigenem Code bestätigt haben, gehört sie natürlich behoben. Die wichtigsten Gegenmaßnahmen bei reflektiertem XSS:

• Kontextabhängiges Output-Encoding: In PHP etwa htmlspecialchars() statt roher Ausgabe, damit < und > zu < und > werden.
• Content Security Policy (CSP): eine restriktive CSP mit Nonce für Inline-Skripte statt unsafe-inline.
• Eingabevalidierung: Nutzereingaben serverseitig prüfen und normalisieren, bevor sie verarbeitet werden.

Eine tiefere Behandlung der Behebung sprengt diesen Rahmen, hier geht es um das Finden. Für die Abwehrseite lohnt der Blick in unseren Artikel zum XSS-Schutz in ReactJS.

Alternativen zu XSStrike

Kein Tool deckt alles ab. Ordnen Sie XSStrike in ein größeres Werkzeug-Ökosystem ein:

In der Praxis kombinieren viele Tester Dalfox und XSStrike: Dalfox für den schnellen Breiten-Scan über viele Endpunkte nach einer Recon-Phase, XSStrike anschließend für die tiefere Analyse einzelner interessanter Ziele. Für gespeichertes und komplexes DOM-XSS führt an Burp Suite oft kein Weg vorbei.

Legale Übungsziele zum Trainieren

Testen Sie XSStrike niemals gegen fremde Live-Systeme ohne Erlaubnis. Zum Üben gibt es bewusst verwundbare Umgebungen:

• testphp.vulnweb.com (Acunetix VulnWeb): dauerhaft online und für Sicherheitstests freigegeben, ideal für einen ersten --crawl-Durchlauf.
• DVWA (Damn Vulnerable Web Application): PHP-App mit einstellbaren Sicherheitsstufen, lokal deploybar.
• OWASP Juice Shop: moderne Node.js-App mit vielen eingebauten Lücken, lokal per Docker startbar.
• PortSwigger Web Security Academy: über 30 dedizierte XSS-Labs mit strukturiertem Lernpfad.
• Google XSS Game und alert(1) to win: browserbasierte Filter-Umgehungs-Challenges.
• bWAPP, OWASP WebGoat, HackThisSite: weitere lektions- und missionsbasierte Plattformen.

Für die ersten Schritte ist eine lokal aufgesetzte App (http://127.0.0.1/...) der sicherste Weg, weil Sie dort volle Kontrolle haben und niemandem schaden.

Rechtlicher Rahmen

Der Einsatz von XSStrike gegen Systeme, für die Sie keine ausdrückliche Genehmigung besitzen, ist in Deutschland strafbar. Einschlägig ist unter anderem § 202a StGB ("Ausspähen von Daten"). Auch das bloße unbefugte Scannen kann bereits Straftatbestände berühren. Holen Sie vor jedem Test gegen fremde Systeme eine schriftliche Beauftragung ein, bei Bug-Bounty-Programmen ergibt sich die Erlaubnis aus deren Regeln (Scope). Im Zweifel gilt: nur eigene Systeme oder ausgewiesene Übungsumgebungen.

Fazit

XSStrike ist auch 2026 ein leistungsfähiger Scanner für reflektiertes XSS, mit einem klugen Ansatz aus Kontextanalyse und Fuzzing-gestützter Payload-Generierung. Wer die richtigen Flags kennt (und die falschen wie --params, -o oder --fuzz meidet), deckt mit wenigen Befehlen Einzelseiten-Scans, Crawling, POST/JSON-Tests, WAF-Fuzzing und Blind XSS ab.

Gleichzeitig sollten Sie die Grenzen kennen: Der Maintainer ist seit April 2025 inaktiv, gespeichertes XSS deckt das Tool kaum ab, und DOM-Funde brauchen manuelle Verifikation. Für ein vollständiges Bild kombinieren Sie XSStrike mit Dalfox oder Burp Suite. Und egal wie gut das Werkzeug ist: Es ersetzt weder das Verständnis der XSS-Grundlagen noch die ausdrückliche Erlaubnis, ein Ziel überhaupt testen zu dürfen.

Häufige Fragen zu XSStrike

Heißt das Fuzzing-Flag --fuzz oder --fuzzer?

Das korrekte Kommandozeilen-Flag ist --fuzzer. fuzz ist nur die interne Zielvariable im Quellcode. Anleitungen, die --fuzz nennen, sind an dieser Stelle schlicht falsch, der Befehl funktioniert so nicht.

Warum bricht die Installation mit "externally-managed-environment" ab?

Moderne Debian-, Ubuntu- und Kali-Systeme schützen ihr System-Python nach PEP 668. Nutzen Sie entweder eine virtuelle Umgebung (python3 -m venv venv && source venv/bin/activate) oder hängen Sie --break-system-packages an den pip install-Befehl. Die virtuelle Umgebung ist der sauberere Weg.

Findet XSStrike auch gespeichertes (Stored) XSS?

In der Praxis kaum. XSStrike ist auf reflektiertes XSS ausgelegt. Für gespeichertes XSS sind Tools wie Dalfox oder Burp Suite besser geeignet, weil dort der Payload und die Ausführungsstelle auseinanderfallen und ein reiner Query-Scanner das schwer erfasst.

Wird XSStrike 2026 noch weiterentwickelt?

Das Repository ist nicht archiviert, aber der Maintainer hat seit dem 26. April 2025 keinen Code mehr gepusht. Die letzte Release ist 3.1.6 vom März 2025. Aktivität kommt fast nur noch aus offenen Community-Pull-Requests. Das Tool ist stabil nutzbar, größere neue Features sind aber nicht in Sicht.