Web-Security-Tests mit Open-Source-Werkzeugen

Eine der größten Herausforderungen bei der Integration von Sicherheitsüberprüfungen in agilen Projekten besteht in deren häufigen Rollouts. Die Geschwindigkeit, mit der sie Software ausliefern, steht oft im direkten Gegensatz zu den Anforderungen moderner Sicherheitsarchitekturen: Meist gehen Entwickler nur kurz vor der Veröffentlichung oder dem Liveschalten den gravierendsten Sicherheitslücken nach, mit manuellen Code-Reviews und händischen Penetrationstests. Auch Red Team Assessments oder ähnliche Vorgehensweisen zu integrieren, fällt schwer. Unter diesen Umständen wundert es nicht, dass das ganze Thema Security häufig als bremsend oder als Flaschenhals wahrgenommen wird. Dass sich so nicht alle Releases einer ausreichenden Sicherheitsüberprüfung unterziehen lassen, birgt ein nicht zu unterschätzendes Sicherheitsrisiko.

Vor allem die Automatisierung im Dev­Ops-Umfeld half, die schnelle Release-­Abfolge agiler Methoden zu erreichen: Möglichst viele Teile der Build-Pipeline inklusive des Testens sollen da automatisiert, skalierbar und reproduzierbar ablaufen. DevSecOps greift diesen Ansatz auf und erweitert ihn um spezialisierte Sicherheitsüberprüfungen in automatisierten Checks. Aber wie bei DevOps kommt es für die Integration von Security in agile Projekte nicht nur auf die Werkzeuge und die richtige Automatisierung an, sondern auch auf organisatorische und teamkulturelle Aspekte. Auch die Verantwortlichkeiten, der Umgang mit Ergebnissen und viele weitere Punkte sind zu klären, was neben prozesstechnischen Aspekten auch organisatorische Themen tangiert. Rein technisch orientierte Maßnahmen ver­lieren schnell wieder an Wirkung, wenn Kunden oder Product Owner nicht ein­gebunden sind, beispielsweise rund um Security-­Requirements, Security-Sprints oder Budgets. Dieser Artikel konzentriert sich jedoch auf die technischen Aspekte der Integration, auch wenn es damit allein sicher nicht getan ist.

Integrationsmöglichkeiten von Werkzeugen

Bis zum Rollout durchgezogene Build-Pipe­lines (sogenannte CI/CD-Pipelines – Continuous Integration und Continuous Delivery) erstellen automatisch Release-­Inhalte und Integrationstestsysteme, wo sich vor dem Liveschalten noch technische und fachliche Tests durchführen lassen. Je nach Architektur des zu entwickelnden Softwaresystems können diese auch automatisierte User-Interface-Tests oder Webservice-Tests beinhalten.

Genau an dieser Stelle können diverse Werkzeuge ansetzen, um den Code und das Deployment vor dem Liveschalten auf Sicherheit zu überprüfen. Solche Security-­Werkzeuge lassen sich grob gesehen in die folgenden drei Kategorien unterteilen:

DAST (Dynamic Application Security Testing): DAST-Werkzeuge betrachten die zu prüfende Webanwendung oder Web-API aus Sicht eines Angreifers von außen, also als Blackbox. Hierzu werden die Eingangskanäle, also sämtliche Parameter, mit unterschiedlichen Angriffsmustern befüllt. Anhand einer Heuristik versucht das Werkzeug zu erkennen, ob ein Angriffsmuster erfolgreich war und eine Sicherheitslücke bewiesen oder zumindest ein Verdacht darauf gefunden wurde. Der Einsatz von DAST-Werkzeugen eignet sich besonders dann, wenn die zu entwickelnde Software bereits einen lauffähigen Stand erreicht hat und eine Testabdeckung mit Integrationstests auf UI- oder Serviceebene besteht.

SAST (Static Application Security Testing): SAST-Werkzeuge scannen den Quellcode beziehungsweise Bytecode der Anwendung auf Sicherheitslücken. Einfachere SAST-Werkzeuge betrachten nur die Sinks, also die potenziell unsicheren Stellen, ohne eine Verbindung mit potenziell manipulierbaren Daten herzustellen. Professionellere Werkzeuge prüfen auch dies und können damit genauere Aus­sagen zur tatsächlichen Ausnutzbarkeit treffen.

Im Vergleich zu DAST-Tools haben SAST-Werkzeuge einen höheren Ab­deckungsgrad der Anwendung, weil der gesamte Quell- oder Bytecode gescannt werden kann. Ebenso sind diese Werkzeuge bereits in einer frühen Entwicklungs­phase mit noch nicht deployfähigem Code verwendbar. Darüber hinaus existieren Werkzeuge zum Überprüfen der Abhängigkeiten auf veraltete und unsichere ­Bibliotheken. Diese Tools gleichen Listen bekannter verwundbarer Komponenten gegen die verwendeten Bibliotheken ab. Formal findet hier zwar keine Codeanalyse statt – die Deployments werden statisch auf deren Abhängigkeiten hin geprüft –, dennoch ist eine grobe Zuordnung dieser Werkzeuge zu den SAST-Werkzeugen möglich.

IAST (Interactive Application Se­curity Testing): Diese relativ neue Kategorie kann als dynamische Codeanalyse betrachtet werden: Hierbei dient die Bytecode-Instrumentierung einer Testumgebung dazu, die Anwendung zur Laufzeit einer Whitebox-Analyse zu unterziehen, während das Werkzeug den tatsächlichen Datenfluss in der Anwendung beobachtet. Dies ermöglicht eine einfache, nahtlose Integration in bereits automatisierte Tests.

Da die drei Werkzeugkategorien unterschiedliche Sichtweisen (von innen versus von außen) und damit andere Schwerpunkte abdecken, ist eine Kombination von Tools aus mehreren Kategorien sinnvoll. Manche Werkzeuge eignen sich für einen permanenten Einsatz bei jedem Build, also zum Beispiel nach jedem Commit, andere wiederum haben längere Laufzeiten und sind eher für Nightly Builds ­geeignet.

Im Bereich der kommerziellen Werkzeuge gibt es Vertreter in allen drei Kategorien. Im Falle von Open-Source-Tools gibt es gute Vertreter im DAST- und SAST-Bereich.

In keinem Fall können diese Werkzeuge einen vollständigen Penetrationstest der Software ersetzen, aber sie bieten eine gute Baseline von skalierbaren automatisierten Checks. Damit können die Pentests eher bei den relevanten größeren Releases stattfinden (oder wenn sehr sensitive Codeanteile verändert wurden), während die restlichen Releases dank der automatischen Checks trotzdem nicht ungeprüft live gehen.

Einbindung von Open-Source-DAST-Werkzeugen

Als einen ersten einfachen Scan kann man die Laufzeitumgebung auf typische, einfach zu findende Konfigurationsschwächen oder fehlende Härtungsmaßnahmen hin überprüfen. Oft ergeben sich die schnellsten Ergebnisse durch Konfigurationsfehler, beispielsweise das Fehlen von härtenden Response-Headern oder nicht entfernte Default-Komponenten wie Monitoringseiten in Containern. Doch derlei Fehler in der Konfiguration der Laufzeit­umgebung zeigen sich manchmal erst in der Produktion, wenn die Testumgebung nicht identisch zur Produktion konfiguriert ist. Daher eignen sich für diese Checks einfache Werkzeuge, die so defensiv wie möglich arbeiten. So können Pentester diese auch regelmäßig gegen die Produktiv­umgebung laufen lassen, ohne das Risiko eines Schadens signifikant zu erhöhen.