Seminar OWASP ZAP – WebSocket-Sicherheitstests

WebSocket-Verbindungen beginnen mit einem HTTP-Handshake, wechseln danach aber in einen bidirektionalen Nachrichtenkanal. Klassische Request-Response-Tests erfassen Zustände, Reihenfolgen und serverinitiierte Nachrichten daher nur unvollständig.

Das Seminar verbindet Handshakeanalyse, Kanalbeobachtung und kontrollierte Nachrichtenmanipulation zu einem reproduzierbaren Testverfahren.

Inhaltsübersicht

1. Seminarziel und Arbeitsweise
2. Handshake und Kanalaufbau analysieren
3. WebSocket-Ansicht und Nachrichtenmodell
4. Scope, Sitzung und Rollen abgrenzen
5. Breakpoints und manuelle Manipulation
6. Wiederholung, Payloadtests und Zustandsfolgen
7. Passive Analyse, Skripte und Befundnachweis
8. Praxisübungen und Arbeitsaufträge
9. Zielgruppe, Voraussetzungen und Arbeitsumgebung

Seminarziel

WebSocket-Verbindungen über ZAP erfassen, Nachrichten und Zustände systematisch prüfen, sicher manipulieren und belastbare Befunde mit Gegenproben erstellen.

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. Handshake und Kanalaufbau analysieren

Der HTTP-Upgrade-Request legt Origin, Cookies, Subprotokolle und weitere Sicherheitsparameter des späteren Kanals fest.

1. Upgrade-Request und Serverantwort in der History lokalisieren.
2. Origin, Authentifizierung, Cookies und Subprotokoll prüfen.
3. Erfolgs- und Fehlerhandshake vergleichen.
4. Kanal-ID und zugehörige Anwendungssitzung dokumentieren.

Kontrollpunkte: Kanal ist eindeutig einem Benutzer zugeordnet; Handshakeprüfung umfasst negative Origins und fehlende Credentials.

2. WebSocket-Ansicht und Nachrichtenmodell

Nachrichten werden nach Kanal, Richtung, Opcode, Zeit und Inhalt strukturiert ausgewertet.

1. Kanäle und Nachrichten in der WebSocket-Ansicht filtern.
2. Client- und Serverrichtung getrennt betrachten.
3. Text-, Binär-, Ping-, Pong- und Close-Nachrichten unterscheiden.
4. Nachrichtentypen und erwartete Zustandsübergänge katalogisieren.

Kontrollpunkte: Kernnachrichten sind fachlichen Aktionen zugeordnet; Binärdaten werden nicht ohne geeignete Interpretation bewertet.

3. Scope, Sitzung und Rollen abgrenzen

Ein offener Kanal kann nach Rollenwechsel, Logout oder Tokenablauf weiterbestehen. Diese Übergänge werden ausdrücklich geprüft.

1. WebSocket-Host in den passenden Context aufnehmen.
2. Kanäle für mehrere Testbenutzer getrennt aufzeichnen.
3. Logout, Tokenablauf und erneute Anmeldung auslösen.
4. Weiterverwendung alter Kanäle und Nachrichtenberechtigungen prüfen.

Kontrollpunkte: Sitzungen verschiedener Benutzer werden nicht vermischt; Logoutwirkung wird am Kanal und am Backendzustand kontrolliert.

4. Breakpoints und manuelle Manipulation

WebSocket-Breakpoints stoppen ausgewählte Nachrichten und erlauben Änderungen vor der Weiterleitung.

1. Breakpoint auf Richtung, Kanal oder Inhalt begrenzen.
2. Objektkennungen, Aktionen und Werte kontrolliert verändern.
3. Nachricht weiterleiten, verwerfen oder duplizieren.
4. Serverantwort und fachlichen Seiteneffekt mit Referenz vergleichen.

Kontrollpunkte: Originalnachricht bleibt als Referenz erhalten; Änderung betrifft nur den freigegebenen Testfall.

5. Wiederholung, Payloadtests und Zustandsfolgen

Nachrichten werden einzeln oder in Sequenzen variiert; Wiederholung und Reihenfolge können eigene Sicherheitsprobleme auslösen.

1. Repräsentative Nachricht wiederholen und Idempotenz prüfen.
2. Grenzwerte, Typen und nicht erlaubte Aktionen variieren.
3. Nachrichten in falscher Reihenfolge oder ohne Vorstufe senden.
4. Rate, Wiederholungsschutz und serverseitige Validierung beobachten.

Kontrollpunkte: Seiteneffekte werden durch unabhängiges Lesen bestätigt; Payloadmenge bleibt klein und hypothesengeleitet.

6. Passive Analyse, Skripte und Befundnachweis

Wiederkehrende Prüfungen können durch passive Skripte und kontrollierte Automatisierung unterstützt werden.

1. Nachrichten auf sensible Daten, Fehlermeldungen und unsichere Muster prüfen.
2. Kleine passive Skriptregel für ein eindeutiges Muster erstellen.
3. Handshake, Kanalzustand, Original- und Testnachricht dokumentieren.
4. Retestschritte und erwartetes sicheres Verhalten formulieren.

Kontrollpunkte: Alert enthält konkrete Nachrichtenevidenz; Befund ist aus definierter Sitzung reproduzierbar.

Praxisübungen und Arbeitsaufträge

• Analyse eines WebSocket-Handshakes mit positiver und negativer Kontrolle
• Zuordnung von Kanälen und Nachrichten zu zwei Benutzerrollen
• Breakpoint-gestützte Änderung einer Nachricht
• Prüfung von Wiederholung und falscher Nachrichtenreihenfolge
• Erstellung einer kleinen passiven Skriptregel
• Dokumentation eines reproduzierbaren WebSocket-Befunds

Zielgruppe

Penetration Tester, Application-Security-Teams, Entwickler und Qualitätssicherung von Echtzeit- oder Push-Anwendungen

Voraussetzungen

ZAP-Grundlagen, HTTP- und JavaScript-Kenntnisse sowie ein freigegebenes WebSocket-Labor

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.