Seminar OWASP ZAP – Clientseitige Schwachstellen und DOM-XSS-Tests

Clientseitige Schwachstellen entstehen dort, wo Browserdaten, DOM-Manipulation und dynamischer Code zusammenspielen. Serverantworten allein zeigen diese Zusammenhänge häufig nicht.

Die Schulung nutzt Client Side Integration, Browserereignisse und browserbasierte Scanregeln. Automatische Hinweise werden stets mit manueller Datenfluss- und Kontextanalyse verbunden.

Inhaltsübersicht

1. Seminarziel und Arbeitsweise
2. Clientseitige Angriffsfläche erfassen
3. Browserereignisse und Client Map analysieren
4. Passive clientseitige Regeln einsetzen
5. DOM-XSS-Regel kontrolliert ausführen
6. Treffer manuell validieren
7. Schutzmaßnahmen technisch bewerten
8. Praxisübungen und Arbeitsaufträge
9. Zielgruppe, Voraussetzungen und Arbeitsumgebung

Seminarziel

Clientseitige Datenflüsse und DOM-XSS-Risiken mit ZAP erkennen, reproduzieren und so dokumentieren, dass Ursache, Ausführungskontext und wirksame Abhilfe klar werden.

Arbeitsweise

Vortrag, Demonstrationen und praktische Übungen werden in kurzen Arbeitszyklen verbunden. Jeder Themenblock beginnt mit einem klar abgegrenzten Testziel, führt über die Konfiguration und Durchführung zur fachlichen Prüfung und endet mit dokumentierten Kontrollpunkten. Belastende oder angreifende Funktionen werden ausschließlich in ausdrücklich freigegebenen Labor- und Zielumgebungen eingesetzt.

Schrittweise Seminarinhalte

1. Clientseitige Angriffsfläche erfassen

DOM, URI-Fragmente, Browser Storage, Nachrichtenkanäle und dynamische Ressourcen bilden eine eigene Angriffsfläche.

1. Relevante Eingabequellen und DOM-Änderungen beobachten.
2. Local Storage, Session Storage und clientseitige Zustände inventarisieren.
3. Fragmente und dynamisch erzeugte URLs in der Client Map prüfen.
4. Third-Party-Skripte und Vertrauensgrenzen kennzeichnen.

Kontrollpunkte: Sensible Datenquellen sind vollständig erfasst; externe Skripte werden als eigene Vertrauensdomäne behandelt.

2. Browserereignisse und Client Map analysieren

Die ZAP Browser Extension liefert Ereignisse, die in klassischen HTTP-Ansichten fehlen.

1. Anwendung aus ZAP heraus starten.
2. Client Map und Details bei Benutzeraktionen beobachten.
3. DOM-Knoten mit zugehörigen Requests und Scripts korrelieren.
4. Unterschiede zwischen Sites Tree und Client Map dokumentieren.

Kontrollpunkte: Kritische Navigation ist reproduzierbar; Browserereignisse lassen sich einer konkreten UI-Aktion zuordnen.

3. Passive clientseitige Regeln einsetzen

Passive Client-Analyse bewertet browserseitig sichtbare Daten ohne zusätzliche Angriffsrequests.

1. Client-Passive-Scan aktivieren und Regelumfang prüfen.
2. Storage-, DOM- und Scriptbefunde nach Evidenz filtern.
3. Risiko und Confidence gegen den realen Kontext bewerten.
4. Dubletten und wiederkehrende Frameworkmuster kontrollieren.

Kontrollpunkte: Befunde enthalten nachvollziehbare Client-Evidenz; Frameworkartefakte werden nicht pauschal als Schwachstelle bewertet.

4. DOM-XSS-Regel kontrolliert ausführen

Die DOM-XSS-Regel arbeitet browserbasiert und benötigt deutlich mehr Zeit als rein HTTP-basierte Regeln.

1. Zielknoten und Parameter auf potenzielle DOM-Datenflüsse begrenzen.
2. Browser, Wartezeiten und Scan Policy konfigurieren.
3. Scanfortschritt und geöffnete Browserinstanzen überwachen.
4. Treffer mit Payload, Quelle, Senke und Ausführungskontext erfassen.

Kontrollpunkte: Scan ist auf freigegebene Eingaben begrenzt; Ausführung wird nicht allein aus reflektiertem Text abgeleitet.

5. Treffer manuell validieren

Ein belastbarer DOM-XSS-Nachweis zeigt kontrollierte Codeausführung im erwarteten Browserkontext.

1. Minimalen Auslöser aus dem Scannerrequest ableiten.
2. Datenfluss von Quelle zu Senke nachvollziehen.
3. Encoding-, Parsing- und Timingabhängigkeiten prüfen.
4. Gegenprobe mit neutralisiertem Payload oder korrigiertem Kontext durchführen.

Kontrollpunkte: Nachweis funktioniert in einer frischen Sitzung; Auswirkung und notwendige Benutzeraktion sind beschrieben.

6. Schutzmaßnahmen technisch bewerten

Abhilfe hängt von Einfügekontext, API und Datenfluss ab; pauschales Escaping genügt nicht.

1. Sichere DOM-APIs und kontextgerechtes Encoding unterscheiden.
2. Sanitizing und Trusted-Data-Grenzen prüfen.
3. Content Security Policy als zusätzliche Schutzschicht bewerten.
4. Regressionstest und sichere Gegenprobe dokumentieren.

Kontrollpunkte: Empfehlung passt zum konkreten DOM-Kontext; Schutzmaßnahme wird mit demselben Testfall verifiziert.

Praxisübungen und Arbeitsaufträge

• Aufbau einer Client Map mit Fragment- und Storage-Analyse
• Passive Prüfung browserseitiger Datenflüsse
• Kontrollierter DOM-XSS-Scan eines abgegrenzten Eingabepunkts
• Manuelle Quelle-Senke-Analyse und Gegenprobe
• Bewertung einer technischen Abhilfe mit Regressionstest

Zielgruppe

Penetration Tester, Frontend-Security-Teams, Application-Security-Engineers und erfahrene Webentwickler

Voraussetzungen

ZAP-Grundlagen, JavaScript- und DOM-Grundkenntnisse sowie Zugriff auf eine freigegebene moderne Testanwendung

Arbeitsumgebung

Verwendet werden eine isolierte ZAP-Installation oder ein geeigneter Container, ein getrenntes Browserprofil, eine ausdrücklich freigegebene Laboranwendung, vorbereitete Testkonten und versionskontrollierbare Konfigurationsdateien. Produktive Ziele, persönliche Konten und nicht genehmigte Drittsysteme sind ausgeschlossen.