Seminar OWASP ZAP – Intensivseminar Erweiterung, Scripting und Scan-Regeln

Das Intensivformat führt von schnellen Skriptanpassungen bis zu getesteten Java-Add-ons. Die Auswahl des Erweiterungsmechanismus erfolgt nach Lebensdauer, Leistung, Verteilung und Sicherheitsrisiko.

Alle Übungen arbeiten mit derselben Beispielanforderung, die zunächst als Zest-Ablauf, danach als Skript und schließlich als native Scan-Regel umgesetzt wird. Dadurch werden Grenzen und Wartungskosten unmittelbar vergleichbar.

Inhaltsübersicht

1. Seminarziel und Arbeitsweise
2. Erweiterungslandkarte und Entwicklungsprofil
3. Zest aufzeichnen und strukturieren
4. JavaScript- und Groovy-Skripte
5. HTTP-Sender- und Replacer-Logik
6. Authentifizierungs- und Session-Skripte
7. Passive und aktive Skriptregeln
8. WebSocket- und Client-Skripte
9. Add-on-Projekt und Lifecycle
10. Native passive und aktive Scan-Regeln
11. Tests, Paketierung und Wartung
12. Praxisübungen und Arbeitsaufträge
13. Zielgruppe, Voraussetzungen und Arbeitsumgebung

Seminarziel

Den geeigneten ZAP-Erweiterungsmechanismus auswählen und wartbare Skripte, Scan-Regeln sowie Add-ons mit Tests, sicherer Datenbehandlung und reproduzierbarer Paketierung entwickeln.

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. Erweiterungslandkarte und Entwicklungsprofil

Skripte, Automation Jobs, API-Orchestrierung und Java-Add-ons werden nach Einsatzbereich und Wartungskosten verglichen.

1. Anforderung nach Trigger, Datenzugriff und Laufzeit klassifizieren.
2. Skript- und Add-on-Typen den Anforderungen zuordnen.
3. Isoliertes Entwicklungsprofil und Testziel einrichten.
4. Versions- und Freigabestrategie festlegen.

Kontrollpunkte: Mechanismuswahl ist begründet; Entwicklung erfolgt außerhalb produktiver Profile.

2. Zest aufzeichnen und strukturieren

Zest eignet sich für wiederholbare weborientierte Abläufe und lässt sich aus aufgezeichnetem Verkehr entwickeln.

1. Beispielablauf als Zest-Skript aufzeichnen.
2. Assertions, Variablen und Bedingungen ergänzen.
3. Datenabhängigkeiten und Sessionzustand behandeln.
4. Skript in frischer Sitzung wiederholen.

Kontrollpunkte: Ablauf ist deterministisch; Credentials sind parametriert.

3. JavaScript- und Groovy-Skripte

Allgemeine Script Engines ermöglichen flexible Logik für Nachrichten, Authentifizierung und Scanunterstützung.

1. Engine und Script Console konfigurieren.
2. API-Objekte und Nachrichten sicher lesen und verändern.
3. Parameter, Logging und Fehlerbehandlung implementieren.
4. Skriptdateien versionieren und automatisiert laden.

Kontrollpunkte: Skript verändert nur vorgesehene Nachrichten; Logs enthalten keine Secrets.

4. HTTP-Sender- und Replacer-Logik

Zentrale Nachrichtenmanipulation eignet sich für Header, Tokens, Markierungen und organisationsspezifische Transportregeln.

1. Trigger und Scope der Manipulation begrenzen.
2. Header oder Parameter deterministisch ergänzen.
3. Dubletten und rekursive Veränderungen verhindern.
4. Verhalten bei mehreren Hosts und Benutzern testen.

Kontrollpunkte: Manipulation bleibt im freigegebenen Context; Originalwert lässt sich bei Bedarf rekonstruieren.

5. Authentifizierungs- und Session-Skripte

Komplexe Login- und Sitzungsverfahren werden mit klaren Parametern und Verifikationsregeln umgesetzt.

1. Loginfolge und Tokenabhängigkeiten modellieren.
2. Credentials über Benutzerparameter beziehen.
3. Erfolg, Abmeldung und Fehler eindeutig erkennen.
4. Neuanmeldung und parallele Benutzer testen.

Kontrollpunkte: Skript funktioniert ohne fest codierte Konten; Fehlerzustand führt nicht zu anonymem Tiefenscan.

6. Passive und aktive Skriptregeln

Skriptbasierte Regeln erlauben schnelle Prototypen, benötigen aber dieselbe Evidenz- und False-Positive-Disziplin wie native Regeln.

1. Passive Regel für vorhandene Antworten schreiben.
2. Aktive Regel mit Baseline und Payload entwickeln.
3. Alertdaten vollständig und präzise setzen.
4. Positive und negative Laborfälle ausführen.

Kontrollpunkte: Passive Regel sendet keine Requests; aktive Regel besitzt eine robuste Gegenprobe.

7. WebSocket- und Client-Skripte

Browser- und WebSocketdaten erfordern eigene Scripttypen und Ereignismodelle.

1. WebSocket-Nachrichten passiv analysieren.
2. Payloads und Richtung korrekt unterscheiden.
3. Clientseitige Ereignisse und Storage nur datensparsam auswerten.
4. Alerts mit technischer Evidenz aus der richtigen Schicht erzeugen.

Kontrollpunkte: Nachrichtenrichtung ist im Befund eindeutig; Skripte verursachen keine Alert-Flut.

8. Add-on-Projekt und Lifecycle

Für dauerhafte, verteilte Erweiterungen wird ein Add-on mit Manifest, Abhängigkeiten und Lifecycle aufgebaut.

1. Buildumgebung und Add-on-Gerüst erzeugen.
2. Extension, Optionen und Nachrichtenkatalog implementieren.
3. API-Fläche und sichere Standardwerte hinzufügen.
4. Installation und Deinstallation testen.

Kontrollpunkte: Add-on baut ohne lokale Sonderpfade; Deinstallation hinterlässt keinen Zustand.

9. Native passive und aktive Scan-Regeln

Java-Regeln werden auf Leistung, Scan Policy und Testbarkeit ausgelegt.

1. Passive Regel mit Größen- und Dublettenkontrolle implementieren.
2. Aktive Regel mit Angriffsstärke und Abbruchlogik implementieren.
3. Risiko, Confidence, Evidenz und Lösungstexte standardisieren.
4. Technologie- und Eingabevektorbegrenzung ergänzen.

Kontrollpunkte: Regeln respektieren Policy und Scope; Erkennung ist gegen zufällige Antwortänderungen robust.

10. Tests, Paketierung und Wartung

Automatisierte Tests, Leistungsprüfung und Releaseprozess schließen den Entwicklungszyklus.

1. Unit- und Integrationsfälle für Positiv und Negativ schreiben.
2. Große Datenmengen und Parallelität prüfen.
3. Installierbares Paket und Changelog erzeugen.
4. Kompatibilitäts-, Review- und Updateprozess dokumentieren.

Kontrollpunkte: Release ist in frischem Profil installierbar; Regressionstests laufen im Build.

Praxisübungen und Arbeitsaufträge

• Dieselbe Sicherheitsanforderung als Zest, Skript und native Regel umsetzen
• Authentifizierungs- und HTTP-Sender-Skript mit sicheren Parametern
• WebSocket- und clientseitige Scriptanalyse
• Vollständiges Add-on mit passiver und aktiver Java-Regel
• Automatisierte Positiv-, Negativ- und Leistungstests
• Paketierung und Wartungsplan für interne Verteilung

Zielgruppe

Security-Tooling-Entwickler, Java-Entwickler, Application-Security-Engineers und technische Maintainer interner ZAP-Erweiterungen

Voraussetzungen

Sichere ZAP-Kenntnisse, Programmiererfahrung, Java-Grundlagen, Git und Buildwerkzeuge; JavaScript oder Groovy sind hilfreich

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.