Der Niedergang der DAST-Analyse

Viele Organisationen sammeln Daten aus einer Vielzahl von Quellen, beispielsweise von Benutzern, und speichern sie dann in Data Lakes. Heutzutage sind Daten alles und ebenso 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 Ganzes zugänglich. 

Natürlich kamen APIs nicht von alleine. Die traditionelle monolithische Architektur ist anderen, beispielsweise Microservices, gewichen. Heute ist alles modular. Microservices machen jede Anwendung modular und sorgen 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 2019 eine API-angepasste Version seiner bekannten OWASP TOP 10 auf den Markt brachte. Daher muss sich die Anwendungssicherheit in diesem Szenario an diese neue Art der Softwareerstellung anpassen und auf dem neuesten Stand bleiben. 

Im letzten Jahrzehnt hat sich auch die Anwendungssicherheit in Form verschiedener automatisierter und spezialisierter Sicherheitstests weiterentwickelt. Diese Entwicklung der Sicherheitskontrollen scheint jedoch hinterherzuhinken, wie es auch bei der dynamischen Anwendungssicherheitsanalyse (DAST) der Fall ist.

DAST, ein cooler Typ 

Die DAST-Analyse entwickelte sich zu einem „ziemlich“ automatisierten Black-Box-Tool zum Auffinden spezifischer Schwachstellen in Webanwendungen zu einer Zeit, als die einzigen Techniken SAST-Analyse und manuelles Pentesting waren. DASTs entstanden mit dem Versprechen, dem Pentester zu helfen und einige der Lücken in den SAST-Tools zu schließen, wie etwa die Reduzierung von Fehlalarmen und die Reduzierung der Scanzeit. 

Der Ausführungsprozess ist sehr einfach: Aus vordefinierten Regelsätzen werden HTTP-Anfragen an die Webanwendung gesendet und bestimmte Textzeichenfolgen in den Antworten überprüft, um festzustellen, ob Schwachstellen vorliegen. Einfach ausgedrückt versucht die DAST-Analyse, einen Pentester zu simulieren. 

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

• Fehlalarm. Jede Menge falsch positiver Ergebnisse würde eine kurze Überprüfung nach dem Scannen, die sogenannte Triage, erfordern. Eine solche Triage würde oft den Expertenblick eines Cybersicherheitsanalysten erfordern und nimmt selbst für einen Experten wertvolle Zeit in Anspruch, die letztendlich dazu führen kann, dass die Schritte nach dem Scan verlangsamt werden. 
• Zeit. Die Ausführung von Scans dauert einige Zeit, in der Regel 30 Minuten bis 2 Stunden oder auch Tage, je nach Größe der Anwendung. 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. Aber eine gute Pre-Scan-Konfiguration zu bekommen ist nicht so einfach und erfordert meist auch 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 die CI/CD-Pipeline integriert und in CI/CD-Umgebungen sind Agilität und Geschwindigkeit von entscheidender Bedeutung. Jeder Build und jede Bereitstellung sollte nicht länger als ein paar Minuten dauern. 

Dies ist bei DAST-Analysen nicht der Fall. Wie bereits erwähnt, dauert die Ausführung von DAST-Scans Zeit, es braucht Zeit, die Ergebnisse zu überprüfen und Zeit, sie zu konfigurieren. Aber diese Hindernisse sind nicht die einzigen, die Agilität und Geschwindigkeit behindern: 

• Entdecken und Krabbeln. Eines der Hauptmerkmale der DAST-Tools ist ihre Fähigkeit, beim Scannen nahezu jeden Winkel der Anwendung zu durchsuchen und darin zu navigieren. Durch die Anwendung einiger heuristischer Regeln zum Umschreiben von URLs und zum Verfolgen von Links können DAST-Tools zahlreiche Subdomains und Abschnitte von Webanwendungen erkennen und crawlen. Eine andere Version dieses Erkennungsprozesses besteht darin, Proxys zu verwenden und alle zu scannenden Endpunkte zu sammeln. Doch heute, wo die Sicherheit im SDLC nach links rückt, könnten diese Funktionen als Mangel angesehen werden, da sie Zeit erfordern. Glücklicherweise bieten die meisten DAST-Tools im Laufe der Jahre die Möglichkeit, in verschiedenen Formaten anzugeben, welche Anwendungsendpunkte gescannt werden sollen. 
• Entwickler verwenden DAST. Unter dem neuen DevSecOps-Paradigma können Entwickler einige in den Pipelines vorhandene Tools, beispielsweise Sicherheitstools, eigenständig nutzen, um eine größere Agilität im Softwareentwicklungsprozess zu erreichen. Wenn Entwickler die Ergebnisse einer Sicherheitsanalyse aus einer DAST-Analyse selbst überprüfen könnten, würde dies angeblich den gesamten Entwicklungsprozess beschleunigen. In der Theorie. In der Praxis wissen Entwickler nicht immer, was falsch positiv ist und was nicht, oder sie müssen dafür mehr Zeit aufwenden als ein Sicherheitsexperte. Dieses Szenario verringert die Toleranz der DevSecOps-Teams gegenüber Fehlalarmen drastisch und untergräbt das Vertrauen in Sicherheitskontrollen. 

Schließlich hat sich auch die Software selbst geändert. Wie wir eingangs sagten, sind APIs und Microservices die Gegenwart und die Zukunft, und DAST ist dafür gut geeignet: 

• Der DAST identifiziert keine dynamisch generierten Inhalte im Frontend, was heutzutage aufgrund der weit verbreiteten Verwendung von Javascript-Frameworks wie Angular, React, Next, JQuery usw. sehr häufig vorkommt. 
• DAST erkennt einige Arten häufiger API-Schwachstellen, wie z. B. IDOR/BOLA, nicht, da hierfür Kontext aus der Geschäftslogik der Anwendung erforderlich ist, z. B. Benutzerrollen und Berechtigungen. 
• Der DAST hat auch Schwierigkeiten, einige Schutzmauern zu passieren, wie etwa Anti-CSRF-Tokens und verschiedene typische Authentifizierungs-/Autorisierungsmechanismen in APIs, wie etwa OAuth2, SSO und Multi-Faktor-Authentifizierung. Obwohl es möglich ist, einige dieser Hindernisse zu überwinden, würde dies sicherlich die Zeit für die Vorbereitung des Scans verlängern, und jede Anwendung benötigt ihre eigene benutzerdefinierte Konfiguration. 

Wie kann man DAST im Jahr 2023 nutzen, 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 einfache Ergebnisse zu erzielen. Einige Schwachstellen können von jedem DAST-Tool schnell und einfach gefunden werden und weisen eine relativ niedrige Falsch-Positiv-Rate auf. Einige Beispiele sind unsichere oder nicht vorhandene HTTP-Header, Cross Site Scripting oder sogar eine Art SQLi 
• Testen Sie spezifische Sicherheitsanforderungen. Wenn ein Katalog von Sicherheitsanforderungen vorhanden ist, könnte die DAST-Analyse verwendet werden, um eine sehr spezifische Reihe von Tests durchzuführen, 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, Zeit in die Vorbereitung von Konfigurationen zu investieren, die zum Scannen mehrerer Anwendungen mit ähnlichen Funktionen oder Architektur verwendet werden können. Dadurch würden mit nur einer gut durchgeführten Konfiguration die Ausführungszeit und Fehlalarme bei zukünftigen Scans erheblich reduziert. 
• Vermeiden Sie vollständige Scans. Das Scannen der gesamten Anwendung kann lange dauern und jeder Schritt in der CI/CD-Pipeline sollte nur wenige Sekunden oder Minuten dauern. Beschränken Sie stattdessen den Umfang des Scans auf die letzten an der Anwendung vorgenommenen Änderungen 
• Füttern Sie das DAST mit den genauen zu scannenden API-Routen. Wenn Ihr Tool dies unterstützt (empfohlen), testen Sie nur die API-Endpunkte, die Sie analysieren möchten, beispielsweise diejenigen mit Änderungen. Dadurch könnte schrittweise eine Scanabdeckung von 100 % erreicht werden, ohne den CI/CD-Prozess zu verlangsamen. 
• Führen Sie DAST asynchron aus. Wenn der Scan in einer Phase des CI/CD-Zyklus beginnt und eine Weile dauern wird, wäre es eine gute Option, ihn einfach auszuführen, ohne auf seinen Abschluss zu warten. Später, wenn der Vorgang abgeschlossen ist, könnte das verantwortliche Team die Ergebnisse überprüfen oder eine Triage durchführen 

Abgesehen davon bleibt das DAST ein wirklich nützliches Werkzeug für jeden Pentester, da es in der Lage ist, eine große Anzahl von Eingabeparametern in zahlreichen Anwendungen in kurzer Zeit mit einer Reihe vordefinierter Regelsätze zu testen (fuzzen), die das Auffinden vieler Arten von ermöglichen Schwachstellen wie Injektionen und Fehlkonfigurationen. 

Was ein DAST-Tool haben sollte, um Sicherheitstests für APIs durchzuführen 

Bei der Bewertung von DAST oder ähnlichen Tools für API-Sicherheitstests kann es schwierig sein, zu wissen, welches Tool die beste Option ist. Daher finden Sie im Folgenden einige zu verwendende Kriterien: 

• Einfache Integration in eine CI/CD-Pipeline 
• Ermöglicht Ihnen die Auswahl der zu scannenden Anwendungsart: API oder Web mit Front-End 
• Unterstützt mehrere API-Spezifikationsformate, um die genauen zu scannenden API-Pfade anzugeben: Postman-Sammlungen, OpenAPI/Swagger, GraphQL-Introspektion, WADL, WSDL usw. 
• Ermöglicht Ihnen die Auswahl des spezifischen API-Typs zum Testen: REST, GraphQL, SOAP 
• Bietet die Möglichkeit, Vor- und Nachskripte zu definieren, um hochpräzise Konfigurationen zur Erkennung von Schwachstellen in der Geschäftslogik zu generieren 

Zusammenfassend 

Die Art und Weise, wie Software entwickelt wird, hat sich verändert, ebenso wie 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 Softwarekomponente geworden, daher hängt die Generierung sicherer Anwendungen davon ab, dass die darunter liegenden APIs keine Schwachstellen aufweisen. 

APIs müssen sehr schnell getestet und gesichert werden, und obwohl die DAST-Analyse dafür nicht ideal ist, ist es möglich, die Konfiguration der Scans und die Art und Weise, wie sie in die Pipelines integriert werden, zu ändern, um APIs besser und schneller zu analysieren. 

KI: eine neue Hoffnung 

Dieser Beitrag kann nicht enden, ohne künstliche Intelligenz zu erwähnen. 

Die Wahrheit ist, dass jede DAST-Lösung KI nutzen könnte, um viele der in diesem Artikel genannten Nachteile und noch einige mehr zu beheben. Beispielsweise könnte es verwendet werden, um den Erkennungs- und Navigationsprozess durch intelligentes URL-Umschreiben zu verbessern, doppelte oder iterative Anfragen zu vermeiden, Fehlalarme zu reduzieren, komplexe Schwachstellen in der Geschäftslogik zu erkennen ... 

Halten Sie es für möglich, dass KI zum Feuer wird, das den DAST-Phönix wiederbelebt? 

Ernesto Rubio , Cybersicherheitsberater