Der Untergang der DAST-Sicherheitstests

Viele Organisationen sammeln Daten aus verschiedenen Quellen, beispielsweise den Benutzern, und speichern sie anschließend in Data Lakes. Daten sind heutzutage alles, ebenso wie die Fähigkeit, große Datenmengen in kurzer Zeit zu verarbeiten.

Die Nutzung der Daten erfolgt immer über APIs. APIs halten alle Anwendungskomponenten zusammen und machen sie für jeden Clienttyp, beispielsweise einen Benutzer, als eine Einheit zugänglich.

Natürlich kamen APIs nicht alleine. Die traditionelle monolithische Architektur ist anderen wie Microservices gewichen. Heutzutage ist alles modular. Microservices machen jede Anwendung modular und zusammensetzbar für bessere Skalierbarkeit, größere Flexibilität und kürzere Markteinführungszeiten.

Microservices in Kombination mit APIs gelten als die Zukunft der Softwareentwicklung. Das stimmt so sehr, dass OWASP im Jahr 2019 eine API-angepasste Version seiner bekannten OWASP TOP 10 veröffentlichte. In diesem Szenario muss sich die Anwendungssicherheit also sowohl an diese neue Art der Softwareerstellung anpassen als auch mit ihr Schritt halten.

Im letzten Jahrzehnt hat sich auch die Anwendungssicherheit in Form mehrerer automatisierter und spezialisierter Sicherheitstests weiterentwickelt. Die Entwicklung der Sicherheitskontrollen scheint jedoch hinterherzuhinken, und dies ist beim Dynamic Application Security Testing (DAST) der Fall.

DAST, ein netter Kerl

DAST kam als „ziemlich“ automatisches Black-Box-Tool heraus, um bestimmte Schwachstellen in Webanwendungen zu finden, zu einer Zeit, als die einzigen Techniken SAST-Analyse und manuelles Petesting waren. DASTs entstanden mit dem Versprechen, den Pentester zu unterstützen und einige der Lücken in SAST-Tools zu schließen, wie etwa die Reduzierung von Fehlalarmen und die Verkürzung der Scanzeit.

Der laufende Prozess war sehr einfach: Aus einigen vordefinierten Regelsätzen werden HTTP-Anfragen an die Webanwendung gesendet und auf bestimmte Zeichenfolgen in den Antworten geachtet, um festzustellen, ob eine Schwachstelle vorliegt. Mit anderen Worten: DAST versucht, einen Pentester zu simulieren.

Es erübrigt sich zu erwähnen, dass es einige Hauptnachteile gibt: 

• Fehlalarm. Jede Anzahl falsch positiver Ergebnisse würde nach dem Scan eine kurze Überprüfung, die sogenannte Triage, erfordern. Für diese Triage wäre oft die fachmännische Sicht eines Cybersicherheitsanalysten erforderlich, und selbst für einen Experten nimmt es wertvolle Zeit in Anspruch, die letztendlich die Schritte nach dem Scan verlangsamen kann.
• Zeit. Die Ausführung von Scans dauert einige Zeit, in der Regel 30 Minuten bis 2 Stunden, je nach Größe der Anwendung auch Tage. Außerdem hängt die Zeit davon ab, wie gut die Konfiguration ist. Je besser die Konfiguration ist, desto kürzer ist die Ausführungszeit. Das Einrichten einer guten Pre-Scan-Konfiguration ist jedoch nicht so einfach und erfordert in den meisten Fällen einen Cybersicherheitsexperten.

DAST liegt weit hinter der Softwareentwicklung zurück

Die Art und Weise, Software zu entwickeln, hat sich verändert. DAST ist mittlerweile häufig in eine CI/CD-Pipeline integriert und in CI/CD-Umgebungen sind Agilität und Geschwindigkeit die Grundpfeiler. Jede Build- und Bereitstellungspipeline sollte nicht länger als nur ein paar Minuten dauern.

Dies scheint keine Funktion von DAST zu sein. Wie bereits erwähnt, benötigen DAST-Scans Zeit für die Ausführung, Zeit für die Überprüfung der Ergebnisse und Zeit für die Konfiguration. Doch nicht nur diese Fallstricke stehen im Widerspruch zu Agilität und Schnelligkeit:

• Entdecken und Krabbeln. Eine der großartigen Funktionen von DAST ist die Fähigkeit, während des Scanvorgangs fast jeden Teil der Anwendung zu durchsuchen und zu crawlen. Durch die Anwendung einiger heuristischer Regeln zum Umschreiben von URLs und zum Verfolgen von Links können DAST-Tools viele Subdomains und Abschnitte von Webanwendungen erkennen und crawlen. Eine andere Version dieses Erkennungsprozesses besteht darin, den Datenverkehr per Proxy weiterzuleiten und die zu scannenden Endpunkte zu sammeln. Aber in der heutigen Zeit, in der sich die Sicherheit im SDLC nach links verschiebt, könnten diese Funktionen als Mangel angesehen werden, weil sie Zeit brauchen. Glücklicherweise verfügen die meisten DAST-Tools im Laufe der Jahre über die Möglichkeit, anzugeben, welche Endpunkte der Anwendung in verschiedenen Formaten gescannt werden sollen.
• Entwickler verwenden DAST. Unter dem neuen *DevSecOps*-Paradigma können Entwickler einige in den Pipelines vorhandene Tools, wie z. B. Sicherheitstools, eigenständig nutzen. Dadurch soll der Softwareentwicklungsprozess flexibler gestaltet werden. Wenn Entwickler selbst die Ergebnisse einer Sicherheitsanalyse wie DAST überprüfen könnten, würde dies angeblich die gesamte Entwicklung beschleunigen. In der Theorie. In der Praxis fällt es Entwicklern schwer, zu unterscheiden, was falsch positiv ist und was nicht, oder sie müssen dafür mehr Zeit investieren als ein Sicherheitsexperte. Dieses Szenario verringert die Toleranz gegenüber Fehlalarmen von DevSecOps-Teams drastisch und untergräbt das Vertrauen in Sicherheitstests.

Schließlich hat sich auch die Software selbst geändert. Wie eingangs erwähnt, sind APIs und Microservices die Gegenwart und die Zukunft, und DAST ist nicht gut an sie angepasst:

• DAST kann keine dynamisch generierten Inhalte in einem Web-Frontend erkennen, was heutzutage aufgrund der weit verbreiteten Verwendung von Javascript-Frameworks wie Angular, React, Next, JQuery usw. sehr verbreitet ist.
• DAST ist nicht in der Lage, einige Arten üblicher Schwachstellen in APIs wie IDOR/BOLA zu erkennen, da es den Kontext der Geschäftslogik der Anwendung erfordert, wie z. B. Benutzerrollen und Berechtigungen.
• DAST hat auch Schwierigkeiten, einige Schutzmauern zu überwinden, wie Anti-CSRF-Tokens und mehrere typische Authentifizierungs-/Autorisierungsmechanismen in APIs, wie OAuth2, SSO und Multi-Faktor-Authentifizierung. Obwohl es möglich ist, einige dieser Hindernisse zu überwinden, würde dies mit Sicherheit die Zeit für die Vorbereitung des Scans verlängern, und jede Anwendung benötigt ihre eigene Konfiguration.

Wie schafft man DAST im Jahr 2023, ohne beim Versuch zu sterben?

An diesem Punkt ist es ziemlich verlockend zu glauben, dass DAST nutzlos ist, aber das ist nicht der Fall. Viele der oben genannten Mängel können durch die Verwendung von DAST auf andere Weise behoben werden:

• Verwenden Sie DAST erneut, um die niedrig hängenden Früchte zu finden. Einige Schwachstellen sind mit jedem DAST-Tool leicht und schnell zu finden und weisen eine relativ niedrige Falsch-Positiv-Rate auf. Einige Beispiele sind unsichere oder fehlende HTTP-Header, Cross Site Scripting oder sogar eine Art SQLi.
• Testen Sie auf spezifische Sicherheitsanforderungen. Wenn ein Katalog von Sicherheitsanforderungen vorhanden ist, könnte DAST verwendet werden, um eine sehr spezifische Reihe von Tests auszuprobieren, um diese hochwertigen Anforderungen in vielen Anwendungen zu überprüfen.
• Erstellen Sie vorher Konfigurationsvorlagen. Wie bereits erwähnt gilt: Je besser die Konfiguration, desto kürzer die Ausführungszeit. Es wäre eine gute Idee, etwas Zeit in die Vorbereitung einiger Konfigurationen zu investieren, die zum Scannen vieler Anwendungen mit ähnlichen Funktionen oder Architektur verwendet werden können. Dadurch würden mit einer einzigen richtigen Konfiguration die Ausführungszeit und Fehlalarme bei zukünftigen Scans erheblich reduziert.
• Vermeiden Sie vollständige Scans. Das Scannen der gesamten Anwendung kann sehr zeitaufwändig sein und jeder Schritt in einer CI/CD-Pipeline sollte nur wenige Sekunden oder Minuten dauern. Begrenzen Sie stattdessen den Umfang des Scans auf die kürzlich an der Anwendung vorgenommenen Änderungen.
• Füttern Sie das DAST mit den genauen API-Routen zum Scannen. Wenn das Tool dies unterstützt (empfohlen), weisen Sie den Scanner immer an, nur die API-Endpunkte zu testen, die Sie scannen möchten, beispielsweise diejenigen, die Änderungen aufweisen. Dies würde es Ihnen ermöglichen, schrittweise eine 100-prozentige Scanabdeckung zu erreichen, ohne den CI/CD-Prozess zu verlangsamen.
• Führen Sie DAST asynchron aus. Wenn der Scan in einem CI/CD-Schritt gestartet wird und eine Weile dauern wird, wäre es eine gute Option, ihn einfach auszuführen, ohne auf seinen Abschluss zu warten. Später, wenn es abgeschlossen ist, könnte das entsprechende Team die Ergebnisse überprüfen oder eine Triage durchführen.

Abgesehen davon bleibt DAST immer noch ein wirklich praktisches Werkzeug für jeden Pentester, da es mit einigen vordefinierten Regelsätzen in der Lage ist, eine große Menge an Eingabeparametern in vielen Anwendungen in kürzester Zeit zu verfälschen, was das Auffinden vieler Arten von Schwachstellen ermöglicht, wie z Injektionen und Fehlkonfigurationen.

Worauf Sie bei einem DAST-Tool für API-Sicherheitstests achten sollten

Bei der Bewertung von DAST oder ähnlichen Tools für API-Sicherheitstests kann es schwierig sein zu wissen, welches Tool die beste Wahl ist. Nachfolgend finden Sie einige Kriterien, die Sie verwenden können:

• Einfache Integration in eine CI/CD-Pipeline.
• Ermöglicht die Auswahl, welche Art von Anwendung gescannt werden soll: API oder Web mit Frontend.
• Unterstützt mehrere API-Spezifikationsformate, um die genauen zu scannenden API-Routen anzugeben: Postman-Sammlungen, OpenAPI/Swagger, GraphQL-Introspektion, WADL, WSDL usw.
• Ermöglicht die Auswahl des spezifischen Typs der zu testenden API: REST, GraphQL, SOAP.
• Bietet die Möglichkeit, Vor- und Nachbereitungen zu definieren, um Feinabstimmungskonfigurationen zur Erkennung von Schwachstellen in der Geschäftslogik zu generieren.

Um es noch einmal zusammenzufassen:

Die Art und Weise, wie Software entwickelt wird, hat sich verändert, und damit auch die Software selbst. Dank der Vorteile der Verwendung von CI/CD-Pipelines sind Agilität und Geschwindigkeit heute Schlüsselmerkmale jedes SDLC. APIs sind zum Kern jeder neuen Software geworden, daher hängt die Bereitstellung sicherer Anwendungen davon ab, dass die zugrunde liegenden APIs keine Schwachstellen aufweisen.

APIs müssen sehr schnell gesichert werden, und obwohl DAST dafür nicht gut geeignet ist, ist es möglich, die Konfiguration der Scans und die Form ihrer Integration in Pipelines zu ändern, um APIs besser und schneller zu scannen.

KI: Eine neue Hoffnung

Dieser Beitrag kann nicht enden, ohne die künstliche Intelligenz zu erwähnen. Die Wahrheit ist, dass jede Sicherheitslösung KI nutzen könnte, um viele Lücken von DAST zu schließen: Erkennung, Crawling und URL-Umschreiben verbessern, doppelte oder iterative Anfragen verhindern, Fehlalarme verringern, komplexe Schwachstellen in der Geschäftslogik erkennen ...

Vielleicht wird die KI zum Feuer, das den DAST-Phönix wiederbelebt. Was denken Sie?

Ernesto Rubio, Cybersicherheitsanalyst