Seite 4: Pen-Tests finden Einfallstore

Inhaltsverzeichnis

Viele Sicherheitslücken lassen sich nur zur Laufzeit entdecken. Daher bedarf es neben den statischen Analysen einer Fokussierung auf das Laufzeitverhalten der Webanwendung. Das macht einen professionellen Pen-Test unumgänglich. Ein solcher Test ist häufig eine Kombination aus Analysetools und manuellen Tests, um Schwachstellen aufzudecken. Während ein realer Angreifer häufig nur eine einzige Schwachstelle zu finden und auszunutzen braucht, müssen Penetration-Tester die Webapplikation auf alle gängigen Angriffsvektoren überprüfen. Je nach Komplexität der Webanwendung und Zeitaufwand des Testers kann ein Pen-Test durchaus aufwendig sein. Tools zur dynamischen Anwendungsanalyse helfen, die Webanwendung vor den manuellen Pen-Tests auf Schwachstellen zu prüfen und abzusichern.

Die meisten Tools sind sowohl in einer kommerziellen als auch in einer frei erhältlichen Variante verfügbar. Unter den frei erhältlichen Tools ist vor allem OWASP ZAP (Zed Attack Proxy) beliebt. Das Werkzeug ermöglicht das Durchführen automatisierter Sicherheitsscans und unterstützt insbesondere dynamische Anwendungsanalysen. Darüber hinaus enthält ZAP eine Vielzahl zusätzlicher Komponenten für manuelle Scans, Proxyfunktionalitäten für Man-in-the-Middle-Angriffe und vorgefertigte Wörterbuchlisten für Fuzzer-Angriffe. Zur Durchführung dynamischer Anwendungsanalysen kommen vor allem folgende Komponenten zum Einsatz:

Spider Rekursiver: Scan der Webanwendung zum Erfassen aller Ressourcen (URLs). Automated Scanner: Aktives Angreifen der Webanwendung basierend auf bekannten Sicherheitslücken. Forced Browsing: Ausführung aller Requests im Kontext eines bestimmten Nutzers.

Durch diese Komponenten ist ZAP in der Lage, gängige Sicherheitslücken mit der Analyse des Request/Response-Verhaltens der Webanwendung zu identifizieren.

Konfiguration von OWASP ZAP über ZAP UI

OWASP ZAP unterscheidet bei den dynamischen Analysen zwischen Pre-Auth-Scans und Post-Auth-Scans. Erstere schicken Requests an die Webanwendung, ohne an dieser authentifiziert zu sein. Bei Post-Auth-Scans findet vor den eigentlichen Analysen eine Authentifizierung statt, sodass man die Webanwendung innerhalb eines bestimmten Nutzerkontextes testen kann. Zur Konfiguration der Einstellungen bietet OWASP ZAP das Tool ZAP UI an, das auf einem Desktoprechner lokal installiert wird. Über die Oberfläche kann man festlegen, welche Angriffe OWASP ZAP in welcher Intensität (attack strength/threshold) ausführt. Neben den Pre-Auth- und Post-Auth-Scans lassen sich weitere Angriffsmuster konfigurieren, beispielsweise Fuzzer-Angriffe.

Damit OWASP ZAP auch geschützte Anwendungsbereiche analysieren kann, unterstützt das Tool standardmäßig unterschiedliche Authentifizierungsverfahren, beispielsweise formularbasierte Anmeldungen. Hierfür ist die URL der Log-in-Maske sowie der Body für den Log-in POST-Request in der ZAP-Konfiguration anzugeben. Über einen Log-in- und einen Log-out-Indicator erkennt OWASP ZAP darüber hinaus, ob ein Log-in erfolgreich war oder nicht. Im Anschluss sind alle Scans im Kontext des angegebenen Nutzers durchführbar.

Sobald alle OWASP-ZAP-Konfigurationen erstellt sind, können Entwickler sie mit einem ZAP Daemon innerhalb von ZAP UI testen. Über die Oberfläche lässt sich der Daemon direkt starten. Im Anschluss führt er die eingestellten Angriffsmuster aus. Innerhalb der Oberfläche zeigt OWASP ZAP die ermittelten Sicherheitswarnungen direkt an. Diese sind im Anschluss individuell zu prüfen, um False Positives zu vermeiden.

Automatisierung der Scans

OWASP ZAP ist grunsätzlich in zwei Modi ausführbar: Zum einen als lokale Desktopinstallation und zum anderen als Daemon auf einem Server. Somit ist es möglich, OWASP ZAP über einen Build-Server wie Jenkins parametrisiert zu starten und automatisiert dynamische Sicherheitsscans gegen die laufende Anwendung durchzuführen. Alle zuvor in ZAP UI vorgenommenen Einstellungen können verlustfrei als Session File exportiert und einem Stand-Alone ZAP-Daemon übergeben werden, sodass dieser die konfigurierten Angriffe automatisiert und eigenständig ausführt.

Abhängig von den Analyseergebnissen kann der Deployment-Vorgang entweder kontrolliert beendet oder die Software wahlweise auf weitere Target-Server (INT/PROD) installiert werden.

Nach dem Durchlauf der Analysen sind die Reports über die Jenkins-Weboberfläche verfügbar. Die von ZAP erstellten Reports listen nach Abschluss der Analysen die unterschiedlichen Schwachstellen kategorisiert nach Risikolevel auf. Die Analysen decken alle gängigen Angriffe ab. Hierzu gehören beispielsweise Szenarien in den Bereichen SQL Injection, Path Traversal und Cross-Site-Scripting. Zu beachten ist jedoch, dass es auch Sicherheitslücken gibt, die ZAP nicht ohne Weiteres findet. Beispiele hierfür sind Lücken, die durch fachliche Fehler in der Anwendungslogik entstehen.

Zusammenspiel mit der CI/CD-Pipeline

Will man die vorgestellten Tools zur statischen und dynamischen Anwendungsanalyse in den Build-Prozess der jeweiligen Webanwendung integrieren, ergeben sich hieraus dedizierte Schritte, die der jeweilige Build-Server koordiniert ausführen muss. Die folgende Abbildung verdeutlicht den Ablauf des CI/CD-Prozesses mit den integrierten Analysen anhand einer Beispielarchitektur.

Bei jedem Code-Commit wird der neue Code vom zentralen Jenkins-Build-Server aus der Versionsverwaltung ausgecheckt. Anschließend führen OWASP Dependency Check, PMD und FindSecurityBugs die statischen Codeanalysen durch. Innerhalb der Weboberfläche von Jenkins sammeln sich die erstellten Reports. Sofern die Analyseergebnisse den konfigurierten Richtlinien entsprechen, wird die Webanwendung paketiert, auf einem separaten Testserver installiert und ausgeführt. Anschließend startet Jenkins einen OWASP ZAP Daemon im Hintergrund. Basierend auf dem hinterlegten Session File beginnen nun die dynamischen Sicherheitsscans gegen die laufende Webanwendung. Den von ZAP erstellten Report stellt Jenkins nach dem Beenden der Analysen zur Verfügung, sodass die Entwickler die Resultate prüfen können. Abhängig von den gefundenen Issues kann bei Bedarf der Deployment-Vorgang auch an dieser Stelle automatisch stoppen, sodass keine schwerwiegenden Lücken auf Integrations- oder Produktionsanlagen gelangen.

Sollten einige der dynamischen Analysen aufgrund der konfigurierten Angriffsvektoren zu viel Zeit in Anspruch nehmen, können diese auch wahlweise nachts während eines Nightly Builds ausgeführt werden. Dadurch verkürzt sich die Build-Zeit während der täglichen Entwicklung. Gleichzeitig wird die Anwendung während des Nightly Builds ausführlich geprüft.