Fähigkeiten Cross-Site Scripting and HTML Injection Testing
🛡️

Cross-Site Scripting and HTML Injection Testing

Niedriges Risiko ⚡ Enthält Skripte🌐 Netzwerkzugriff

Webanwendungen auf XSS-Schwachstellen testen

Webanwendungen sind ständig XSS-Angriffen ausgesetzt, die Benutzersitzungen und Daten kompromittieren. Diese Fähigkeit bietet Sicherheitsfachleuten systematische Testmethoden, um client-seitige Injection-Schwachstellen zu identifizieren und zu beheben, bevor Angreifer sie ausnutzen.

Unterstützt: Claude Codex Code(CC)
📊 70 Angemessen
1

Die Skill-ZIP herunterladen

2

In Claude hochladen

Gehe zu Einstellungen → Fähigkeiten → Skills → Skill hochladen

3

Einschalten und loslegen

Teste es

Verwendung von "Cross-Site Scripting and HTML Injection Testing". Testen Sie Suchparameter ?q= auf reflektiertes XSS

Erwartetes Ergebnis:

SCHWACHSTELLE: Input wird ohne Encoding reflektiert. Payload <img src=x onerror=alert(document.domain)> wird erfolgreich ausgeführt. Der Server gibt den Suchbegriff im HTML-Body ohne HTML-Entity-Encoding zurück, was beliebige Skriptausführung ermöglicht.

Verwendung von "Cross-Site Scripting and HTML Injection Testing". Analysieren Sie Kommentarfeld auf gespeichertes XSS mit CSP-Schutz

Erwartetes Ergebnis:

GESCHÜTZT: Während Input gespeichert und reflektiert wird, blockiert CSP-Header 'script-src 'self'' die Ausführung von Inline-Skripten. Getestete Alternativvektoren (JSONP-Endpoints, data: URIs) werden ebenfalls von CSP blockiert. Empfehlung: Aktuelle CSP-Konfiguration beibehalten.

Verwendung von "Cross-Site Scripting and HTML Injection Testing". Testen Sie DOM XSS im Single-Page-Application-Routing

Erwartetes Ergebnis:

SCHWACHSTELLE: Routenparameter wird ohne Sanitisierung in innerHTML in Zeile 47 geschrieben. URL /profile/<img src=x onerror=alert(1)> löst Skriptausführung aus. Nur client-seitiger Angriff - Payload erreicht nie Server-Logs.

Sicherheitsaudit

Niedriges Risiko
v1 • 2/24/2026

This skill is documentation for authorized XSS and HTML injection security testing. Static analyzer flagged markdown code examples as threats, but these are educational payloads for penetration testers, not executable malicious code. The skill includes proper legal/ethical guardrails requiring written authorization. Risk is low as content is instructional documentation, not functional exploit code.

1
Gescannte Dateien
500
Analysierte Zeilen
3
befunde
1
Gesamtzahl Audits
Probleme mit niedrigem Risiko (1)
Offensive Security Content
Skill contains detailed instructions for cookie theft, session hijacking, and keylogger injection. While educational, this content could be misused by bad actors without proper authorization frameworks.

Risikofaktoren

⚡ Enthält Skripte (1)
🌐 Netzwerkzugriff (2)
Auditiert von: claude

Qualitätsbewertung

38
Architektur
100
Wartbarkeit
87
Inhalt
50
Community
88
Sicherheit
74
Spezifikationskonformität

Was du bauen kannst

Sicherheitsaudit für Webanwendungen

Umfassende XSS-Schwachstellenbewertung auf Client-Websites vor der Bereitstellung durchführen, um Injection-Schwachstellen zu identifizieren, die Benutzerdaten und Sitzungen kompromittieren könnten.

Entwickler-Sicherheitsschulung

XSS-Beispiele und Payloads in kontrollierten Laborumgebungen verwenden, um Entwicklungsteams über die Grundursachen von Injection-Schwachstellen und Präventionstechniken aufzuklären.

Bug-Bounty-Forschung

Systematisch In-Scope-Anwendungen auf XSS-Schwachstellen mit dokumentierten Payloads und Umgehungstechniken testen, um meldepflichtige Sicherheitsprobleme zu entdecken.

Probiere diese Prompts

Basis-XSS-Erkennung
Analysieren Sie dieses Webanwendungs-Eingabefeld auf XSS-Schwachstellen. Testen Sie mit Basis-Payloads wie <script>alert(1)</script> und <img src=x onerror=alert(1)>. Berichten Sie, ob Input reflektiert wird und ob Skripte ausgeführt werden.
Gespeicherte XSS-Bewertung
Testen Sie das Kommentarsystem dieses Blogs auf gespeichertes XSS. Erstellen Sie ein Testkonto, reichen Sie Payloads in Kommentartexten ein, und überprüfen Sie, ob sie für andere Benutzer bestehen bleiben und ausgeführt werden. Dokumentieren Sie den Injection-Punkt und den erfolgreichen Payload.
DOM-basierte XSS-Analyse
Untersuchen Sie den JavaScript-Code, der URL-Hash-Fragmente und postMessage-Ereignisse verarbeitet. Identifizieren Sie gefährliche Sinks wie innerHTML und eval, die benutzerkontrollierte Daten verarbeiten. Geben Sie Exploitation-Payloads für jedes gefundene verwundbare Muster.
CSP-Umgehungs-Testing
Die Zielseite hat CSP-Header mit script-src 'self' https://cdn.trusted.com. Finden Sie JSONP-Endpunkte auf dem vertrauenswürdigen CDN, die missbraucht werden könnten, um beliebiges JavaScript auszuführen. Testen Sie jeden Endpunkt mit alert(1)-Callback.

Bewährte Verfahren

  • Erhalten Sie immer schriftliche Autorisierung, die Umfang, Ziele und Datenhandhabungsverfahren definiert, bevor Sie testen
  • Verwenden Sie isolierte Testkonten und Umgebungen, um echte Benutzer oder Produktionsdaten nicht zu beeinflussen
  • Dokumentieren Sie alle Findings mit Reproduktionsschritten, Schweregrad-Bewertungen und Behebungsanleitungen für Entwickler

Vermeiden

  • Testen Sie niemals XSS-Payloads auf Produktionssystemen ohne explizite schriftliche Autorisierung des Eigentümers
  • Verwenden Sie keine Wurm-ähnlichen Payloads, die sich automatisch auf andere Benutzer außerhalb Ihres Testumfangs ausbreiten
  • Vermeiden Sie das Exfiltrieren echter Benutzerdaten - erfassen Sie nur Ihre eigenen Test-Cookies zu Demonstrationszwecken

Häufig gestellte Fragen

Ist diese Fähigkeit legal zu verwenden?
Nur wenn Sie explizite schriftliche Autorisierung vom Systemeigentümer haben. Unautorisiertes XSS-Testing verstößt in den meisten Gerichtsbarkeiten gegen Computerkriminalitätsgesetze. Definieren Sie immer Umfang, Ziele und Datenhandhabung in einer unterzeichneten Vereinbarung bevor Sie testen.
Was ist der Unterschied zwischen XSS und HTML-Injection?
XSS beinhaltet JavaScript-Ausführung im Browser des Opfers, was Session-Diebstahl und Aktionen im Namen des Benutzers ermöglicht. HTML-Injection rendert nur HTML-Inhalte ohne Skriptausführung, wird typischerweise für Phishing oder Defacement verwendet, hat aber geringere Auswirkungen.
Warum schlagen Payloads auf modernen Websites fehl?
Moderne Frameworks wie React, Angular und Vue escapen standardmäßig automatisch Output. Zusätzlich blockieren Content Security Policy-Header, Input-Sanitisierungsbibliotheken und WAFs viele traditionelle XSS-Vektoren. Testen Sie mehrere Umgehungstechniken und Encoding-Variationen.
Kann diese Fähigkeit auf Blind XSS testen?
Blind XSS erfordert externe Callback-Server, um verzögerte Ausführung zu erkennen, wenn Payloads gespeichert und später von Administratoren angesehen werden. Diese Fähigkeit dokumentiert die Techniken, aber Sie müssen Ihre eigene Callback-Infrastruktur für Blind-XSS-Tests einrichten.
Was sollte ich tun, wenn ich kritische XSS-Schwachstellen finde?
Dokumentieren Sie die Schwachstelle mit Reproduktionsschritten und Auswirkungsdemonstration nur mit alert(1) - stehlen Sie keine echten Daten. Melden Sie dies sofort an den Systemeigentümer gemäß Ihrer Autorisierungsvereinbarung. Befolgen Sie verantwortungsvolle Offenlegungspraktiken.
Funktioniert dies auf mobilen Apps?
Mobile Apps, die WebView-Komponenten verwenden, können anfällig für XSS sein, wenn sie Webinhalte laden oder URLs akzeptieren. Dieselben Testprinzipien gelten, aber Sie müssen den App-Verkehr mit Tools wie Burp Suite oder Frida für WebView-Inspektion abfangen.