OWASP ZAP erklärt: was es ist und 10 typische Prüfungen

Was ZAP ist

ZAP (Zed Attack Proxy), vielerorts noch OWASP ZAP genannt, ist ein kostenloser Open-Source-Sicherheitsscanner für Webanwendungen. Seine Website beschreibt es als unabhängiges Open-Source-Projekt. Es arbeitet als Proxy zwischen Browser und Anwendung: Es sieht jede Anfrage und jede Antwort und kann sie deshalb analysieren.

Es wird sowohl von Menschen genutzt, die eine App von Hand untersuchen, als auch von automatisierten Abläufen, die es bei jeder Codeänderung starten.

Der Baseline-Scan: passiv, ohne Angriffe

In automatisierten Testabläufen ist meist der Baseline-Modus im Einsatz. Laut ZAP-Dokumentation lässt er den Spider gegen das Ziel laufen (standardmäßig eine Minute), wartet, bis die passive Analyse fertig ist, und meldet die Ergebnisse. Die Dokumentation hält fest, dass das Skript keine echten Angriffe ausführt und höchstens wenige Minuten dauert.

Das ist ein wichtiger Unterschied. Ein passiver Scan liest, was die Anwendung ohnehin jedem Besucher antwortet: Header, Cookies, Seitenquelltext. Ein aktiver Scan schickt erst präparierte Anfragen, um herauszufinden, ob sich die Anwendung austricksen lässt. Deshalb darf er nur auf eigene Systeme oder mit Erlaubnis des Eigentümers gerichtet werden.

10 typische Prüfungen

Die Namen stammen aus der Alarmliste von ZAP. Welche davon auftauchen, hängt von Version und Konfiguration ab, und eine Meldung ist ein Anlass zum Hinschauen, kein Beweis für einen Einbruch.

1. Content Security Policy (CSP) Header Not Set. Der Header fehlt, der dem Browser sagt, woher Skripte geladen werden dürfen. Er begrenzt den Schaden eingeschleusten fremden Codes.
2. Missing Anti-clickjacking Header. Die Seite lässt sich in einen fremden Frame einbetten, und Nutzer können zu einem Klick auf etwas verleitet werden, das sie nicht sehen.
3. X-Content-Type-Options Header Missing. Der Browser darf den Dateityp raten, statt dem Server zu vertrauen.
4. Strict-Transport-Security Header Not Set. Der Browser bekommt nicht die Anweisung, diese Seite immer über HTTPS aufzurufen.
5. Cookie No HttpOnly Flag. Ein Skript auf der Seite kann das Cookie lesen, etwa ein Sitzungs-Cookie.
6. Cookie without SameSite Attribute. Das Cookie wird auch bei Anfragen von fremden Seiten mitgeschickt, was CSRF-Angriffe erleichtert.
7. Server Leaks Version Information via “Server” HTTP Response Header Field. Der Server verrät, welche Software er in welcher Version nutzt.
8. Information Disclosure - Suspicious Comments. Im Seitenquelltext gebliebene Kommentare können einem Angreifer Hinweise geben.
9. Cross-Domain JavaScript Source File Inclusion. Die Seite lädt Skripte von anderen Domains, ihre Sicherheit hängt also auch von diesen ab.
10. Vulnerable JS Library. Die Seite nutzt eine JavaScript-Bibliothek in einer Version mit bekannter Schwachstelle.

Daneben tauchen oft noch „Re-examine Cache-control Directives“, „Permissions Policy Header Not Set“ und „Sub Resource Integrity Attribute Missing“ auf.

Was ein passiver Scan nicht verrät

Ein sauberes Baseline-Ergebnis heißt nicht „die App ist sicher“. Der Scan meldet sich nicht als Nutzer an, prüft nicht, ob ein Elternteil aus einer Klasse in eine andere schauen kann, und versucht nicht, schädliche Daten einzuschleusen. Dafür braucht es Berechtigungstests, die für die konkrete App geschrieben sind, einen aktiven Scan und einen Penetrationstest. Der Baseline-Scan ist ein günstiger, wiederholbarer erster Filter, mehr nicht.

Wie es bei uns aussieht

In ClassKasa, CzynszOK und Kasandro läuft der Baseline-Scan bei jedem Pull Request gegen die gebaute App und lässt den Build bei neuen Funden fehlschlagen. Der Scan meldet sich nicht an, deckt also Bereiche hinter der Anmeldung nicht ab. Einen vollständigen Überblick darüber, was wir in der veinito.-Gruppe prüfen, gibt die Sicherheitsseite.