lessonKey: "script-injection-forum" title: "Stored XSS - Forum Comment Injection" description: "Lernen Sie, wie Script-Injection in benutzergenerierten Inhalten ganze Plattformen durch Stored-XSS-Angriffe kompromittieren kann" difficultyLevel: "intermediate" estimatedDuration: 25 module: "script-injection-forum" steps: - id: "intro" type: "content" title: "Was ist Stored XSS?" 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 es gefährlich ist:** Stored XSS ist besonders gefährlich, weil: 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: "Anfälliges 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-1" 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: "" isCorrect: true points: 10 - id: "img-steal" text: "" isCorrect: true points: 10 - id: "svg-payload" text: "" isCorrect: true points: 10 - id: "iframe-phishing" text: "" isCorrect: true points: 10 - id: "normal-comment" text: "Dies ist ein normaler Kommentar ohne bösartigen Code" isCorrect: false points: 0 maxPoints: 40 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: "Stored-XSS-Angriffsvektoren" content: | Gängige Techniken, die Angreifer bei Stored XSS verwenden: **1. Cookie-Diebstahl** Stiehlt Authentifizierungs-Cookies und ermöglicht Kontoübernahme. Der Angreifer kann dann jeden Benutzer imitieren, der den Kommentar angesehen hat. **2. Session-Hijacking** Extrahiert Session-Token aus dem Browser-Speicher und kompromittiert Benutzersitzungen. **3. Keylogging** Zeichnet jeden Tastendruck auf der Seite auf und erfasst Passwörter und sensible Informationen. **4. Verunstaltung** Ändert den sichtbaren Inhalt für alle Benutzer und beschädigt Reputation und Vertrauen. **5. Phishing-Overlay**

Sitzung abgelaufen - Bitte erneut anmelden

Benutzername:
Passwort:
Zeigt ein gefälschtes Login-Formular über der echten Seite an und erfasst Anmeldeinformationen. **6. Kryptowährungs-Mining** Mined heimlich Kryptowährung mit den CPU-Ressourcen der Besucher. **7. Malware-Verteilung** Leitet Benutzer zu Malware-Downloads oder Drive-by-Download-Angriffen um. - id: "question-2" 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: "Stored XSS verhindern" content: | **Defense-in-Depth-Ansatz:** **1. Eingabevalidierung (Erste Linie)** • 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 "bereinigten" Eingaben - validieren Sie immer **2. Output-Encoding (Kritisch)** Kodieren Sie alle Ausgaben kontextabhängig: **HTML-Kontext:** • < wird zu < • > wird zu > • & wird zu & • " wird zu " • ' wird zu ' **JavaScript-Kontext:** • Verwenden Sie JSON.stringify() für Daten • Escapieren Sie Backslashes und Anführungszeichen **URL-Kontext:** • Verwenden Sie encodeURIComponent() **Vertrauen Sie niemals Inhalten aus der Datenbank** - selbst wenn sie bei der Eingabe validiert wurden, kodieren Sie immer bei der Ausgabe! **3. Content Security Policy (Verteidigungsebene)** Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; style-src 'self' 'unsafe-inline'; img-src 'self' https:; 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 **4. HTTPOnly und Secure 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 **5. Framework-Sicherheitsfunktionen** Moderne Frameworks bieten eingebauten XSS-Schutz: • **React:** Escapt JSX-Inhalte automatisch • **Angular:** Eingebaute Bereinigung mit DomSanitizer • **Vue:** Template-Escaping standardmäßig ⚠️ **Verwenden Sie NIEMALS gefährliche Funktionen:** • React: `dangerouslySetInnerHTML` • Angular: `bypassSecurityTrust...` Methoden • Vue: `v-html` mit Benutzerinhalten • JavaScript: `eval()`, `innerHTML` mit Benutzerdaten **6. Regelmäßige Sicherheitsaudits** • Statische Code-Analyse (SAST-Tools) • Dynamische Sicherheitstests (DAST-Tools) • Penetrationstests • Code-Reviews mit Fokus auf Benutzereingabe-Verarbeitung • Sicherheitsbewusstseins-Schulungen für Entwickler **7. 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 scoring: passingScore: 58 maxTotalPoints: 115 # 70 from questions + up to 45 from discovering XSS vectors