Seminar OWASP ZAP – Add-on-Entwicklung und eigene Scan-Regeln

Standardregeln decken viele technische Schwachstellen ab, jedoch nicht jede organisationsspezifische Fehlkonfiguration, Protokollerweiterung oder proprietäre Anwendungskonvention. Eigene Regeln müssen deshalb sauber in Architektur, Laufzeit und Qualitätssicherung eingebettet werden.

Die Schulung arbeitet mit einem vollständigen Entwicklungszyklus: Quellcode ausführen, Add-on erzeugen, Regel implementieren, Tests schreiben, Leistung prüfen und ein installierbares Paket erstellen.

Inhaltsübersicht

1. Seminarziel und Arbeitsweise
2. Entwicklungsumgebung und Quellstruktur einrichten
3. Add-on-Projekt und Manifest aufbauen
4. Lifecycle, Konfiguration und API integrieren
5. Passive Scan-Regel entwickeln
6. Aktive Scan-Regel entwickeln
7. Regeln automatisiert testen
8. Leistung, Sicherheit und Datenbehandlung prüfen
9. Paketieren, dokumentieren und warten
10. Praxisübungen und Arbeitsaufträge
11. Zielgruppe, Voraussetzungen und Arbeitsumgebung

Seminarziel

Entwicklung eines wartbaren ZAP-Add-ons mit mindestens einer passiven und einer aktiven Scan-Regel einschließlich Tests, Konfiguration, Dokumentation und Paketierung.

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. Entwicklungsumgebung und Quellstruktur einrichten

Die ZAP-Repositories, Gradle-Builds und Laufzeitverzeichnisse werden so eingerichtet, dass Core und Add-ons reproduzierbar gebaut und debuggt werden können.

1. Erforderliche Java- und Buildwerkzeuge prüfen.
2. Quellrepositories auschecken und Abhängigkeiten laden.
3. ZAP aus der Entwicklungsumgebung starten.
4. Ein Add-on im Debugger laden und den Lifecycle beobachten.

Kontrollpunkte: Build und Tests laufen ohne lokale Sonderpfade; die Entwicklungsinstanz verwendet eindeutig erkennbare Profile.

2. Add-on-Projekt und Manifest aufbauen

Ein neues Add-on erhält eine eindeutige Identität, definierte Abhängigkeiten und eine nachvollziehbare Versionierung.

1. Projektgerüst aus dem vorgesehenen Add-on-Template erzeugen.
2. Manifest, Status, Version und Abhängigkeiten konfigurieren.
3. Ressourcen, Nachrichtenkataloge und Hilfetexte strukturieren.
4. Kompatibilitätsgrenzen und optionale Komponenten festlegen.

Kontrollpunkte: Das Add-on lässt sich separat bauen und installieren; Abhängigkeiten sind minimal und explizit.

3. Lifecycle, Konfiguration und API integrieren

Die Erweiterung wird kontrolliert gestartet, beendet und konfiguriert. Externe Steuerung erfolgt nur über klar abgesicherte API-Flächen.

1. Extension-Lifecycle und Hooks implementieren.
2. Optionen mit sicheren Standardwerten bereitstellen.
3. Views und Actions der ZAP API modellieren.
4. Fehler, Berechtigungen und Nebenwirkungen der API behandeln.

Kontrollpunkte: Deinstallation hinterlässt keinen unkontrollierten Zustand; API-Aktionen validieren alle Eingaben.

4. Passive Scan-Regel entwickeln

Passive Regeln analysieren vorhandenen Verkehr, ohne zusätzliche Requests zu senden. Sie eignen sich für Header, Inhalte, Metadaten und organisationsspezifische Muster.

1. Prüfziel, Evidenz und False-Positive-Risiken definieren.
2. Request oder Response effizient auswerten.
3. Alert mit Risiko, Confidence, Evidenz und Lösungstext erzeugen.
4. Große Antworten, Binärdaten und Mehrfachmeldungen kontrollieren.

Kontrollpunkte: Die Regel verändert keinen Verkehr; gleiche Evidenz erzeugt keine unkontrollierte Alert-Flut.

5. Aktive Scan-Regel entwickeln

Aktive Regeln erzeugen gezielte Angriffsrequests. Sie benötigen strikte Grenzen, saubere Baselines und verlässliche Erkennungskriterien.

1. Angriffsvektor und Parameterklasse auswählen.
2. Baseline und Payload-Requests erzeugen.
3. Antworten auf robuste Merkmale und Seiteneffekte prüfen.
4. Abbruch, Angriffsstärke und Alert-Erzeugung implementieren.

Kontrollpunkte: Die Regel respektiert Scan Policy und Strength; die Erkennung beruht nicht auf einem einzelnen instabilen Textfragment.

6. Regeln automatisiert testen

Unit-, Integrations- und Regeltests sichern positive, negative und grenzwertige Fälle ab.

1. Testnachrichten und kontrollierte Zielantworten aufbauen.
2. True Positive und True Negative abdecken.
3. Dubletten, fehlerhafte Encodings und große Datenmengen prüfen.
4. Regressionstests in den Gradle-Build integrieren.

Kontrollpunkte: Jeder Alert-Pfad besitzt mindestens einen positiven Test; Fehlalarme werden durch negative Tests dokumentiert.

7. Leistung, Sicherheit und Datenbehandlung prüfen

Scan-Regeln laufen unter hoher Nachrichtenlast und verarbeiten potenziell sensible Daten. Ressourcenverbrauch und Protokollierung werden begrenzt.

1. CPU-, Speicher- und Requestverhalten messen.
2. Secrets und personenbezogene Inhalte aus Logs fernhalten.
3. Timeouts, Größenlimits und Fehlerisolierung umsetzen.
4. Nebenläufigkeit und wiederholte Ausführung testen.

Kontrollpunkte: Die Regel bleibt bei großen Sitzungen stabil; Debug-Ausgaben enthalten keine sensiblen Nutzdaten.

8. Paketieren, dokumentieren und warten

Ein technisch funktionierendes Add-on wird erst durch Installation, Changelog und Wartungsprozess betrieblich nutzbar.

1. Release-Artefakt und Prüfsummen erzeugen.
2. Installations-, Konfigurations- und Deinstallationsschritte dokumentieren.
3. Versions- und Kompatibilitätsstrategie festlegen.
4. Review, Freigabe und Reaktion auf ZAP-Änderungen organisieren.

Kontrollpunkte: Ein frisches ZAP-Profil kann das Paket installieren; Rollback und Vorgängerversion sind dokumentiert.

Praxisübungen und Arbeitsaufträge

• Erzeugen und Debuggen eines eigenen Add-on-Projekts
• Implementierung einer passiven Regel für eine organisationsspezifische Fehlkonfiguration
• Implementierung einer aktiven Regel mit Baseline, Payload und Gegenprobe
• Aufbau automatisierter Positiv-, Negativ- und Lasttests
• Erstellung eines installierbaren Release-Pakets mit Wartungscheckliste

Zielgruppe

Java-Entwickler, Security-Tooling-Teams, Application-Security-Engineers und Maintainer interner Prüfwerkzeuge

Voraussetzungen

Sichere Java- und Gradle-Kenntnisse, Git-Praxis, ZAP-Anwenderkenntnisse sowie Grundlagen von HTTP und Websicherheit

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.