DAST: 7 Anwendungsfälle, Beispiele, Vor- und Nachteile
Die Fähigkeit von DAST, reale Cyberangriffe zu simulieren und Schwachstellen in Echtzeit aufzudecken, macht es zu einem wertvollen Bestandteil der Cybersicherheits-Toolbox. Wie die Grafik zeigt, hat die Popularität von DAST in den letzten fünf Jahren deutlich zugenommen.
In Anbetracht dessen, dass ein erheblicher Teil der Softwareangriffe die Anwendungsschicht ausnutzt 1 Der Fokus von DAST auf externe Prüfungen wird dadurch noch wichtiger.
Im Folgenden wird erläutert, wie DAST in DevSecOps-Pipelines integriert wird, Compliance-Anforderungen erfüllt und Laufzeit-Schwachstellen aufdeckt, die statische Tools übersehen.
Vor- und Nachteile von DAST
Wie funktioniert DAST?
DAST folgt bei jedem Durchlauf gegen eine Zielanwendung einer wiederholbaren Sequenz.
- Zielidentifizierung: Der Scanner wird auf eine URL oder eine Gruppe von API-Endpunkten ausgerichtet. In CI/CD-Umgebungen wird dies typischerweise einmalig konfiguriert und dann bei jedem Build automatisch ausgelöst.
- Crawling: Das Tool kartiert die Angriffsfläche der Anwendung, indem es Links folgt, Formulare absendet und JavaScript analysiert. So erstellt es ein Verzeichnis aller erreichbaren Eingabefelder und Endpunkte. Moderne Scanner verwenden neben dem Standard-Crawler einen AJAX-Spider, um Single-Page-Anwendungen zu erfassen, die Inhalte dynamisch laden.
- Angriffssimulation: Der Scanner testet jede gefundene Eingabe mit verschiedenen Angriffscodes: SQL-Injection-Strings, XSS-Vektoren, Pfadtraversierungssequenzen, fehlerhafte Header und weitere Schwachstellen aus den OWASP Top 10 und darüber hinaus. Drei Kerntechniken bilden die Grundlage dieser Phase:
- Fuzzing sendet unerwartete oder fehlerhafte Daten, um unbehandelte Fehler auszulösen.
- Manipulation von Parametern, Änderung von Werten in URLs, Cookies und Anfragetexten zum Testen der Eingabevalidierung
- Authentifizierungstests mit dem Ziel der Sitzungsfixierung, Tokenvorhersage und Rechteausweitung über Benutzerrollen hinweg
- Antwortanalyse: Der Scanner wertet jede Antwort auf Indikatoren für eine tatsächliche Schwachstelle aus, wie z. B. Stacktraces, Datenbankfehlermeldungen, Weiterleitungen zu unerwünschten Ressourcen oder zurückgegebene Daten, deren Zugriff kontrolliert werden sollte. Tools, die beweisbasiertes Scannen verwenden, bestätigen die Ausnutzbarkeit, bevor sie ein Problem melden, wodurch Fehlalarme reduziert werden.
- Berichterstattung: Die Ergebnisse werden in einem nach Schweregrad geordneten Bericht zusammengefasst, der den betroffenen Endpunkt, die auslösende Payload und Empfehlungen zur Behebung enthält. Die meisten Enterprise-Scanner geben die Ergebnisse direkt in Jira, GitHub Issues oder SIEM-Plattformen aus, sodass die Befunde ohne manuelle Vorauswahl an das zuständige Team weitergeleitet werden.
- Nachträglicher Test: Sobald eine Korrektur bereitgestellt ist, wird der Scanner erneut gegen den zuvor anfälligen Endpunkt ausgeführt, um zu bestätigen, dass die Schwachstelle behoben ist. Dieser Schritt dient auch als dokumentierter Nachweis für Compliance-Audits.
Die 7 wichtigsten Anwendungsfälle für DAST
1. Integration in den Entwicklungslebenszyklus
DAST ist in die Test- und Staging-Phasen des Softwareentwicklungszyklus integriert, in denen Anwendungen zwar laufen, aber noch nicht produktiv eingesetzt werden. In dieser Phase lassen sich Schwachstellen kostengünstig beheben und bergen kein Kundenrisiko. In CI/CD-Pipelines können Scans bei jedem Build automatisch ausgelöst werden, wodurch Sicherheit zu einem routinemäßigen Bestandteil des Release-Prozesses wird und nicht erst am Ende geprüft wird.
Beispiel aus dem realen Leben
Vor der Integration führte das Sicherheitsteam manuelle Scans durch, die mit dem Release-Zyklus von Park 'N Fly nicht mithalten konnten. Nach der Anbindung von Invicti an die bestehenden Azure DevOps- und Jira-Workflows wurden die Scans bei jedem Build automatisch ausgelöst. Dadurch wurden die Sicherheitsprüfungen von einer vierteljährlichen Überprüfung zu einem Release-Check verlagert. Das Team sparte so die Arbeitslast eines Vollzeitmitarbeiters ein. 2
2-Realistische Angriffssimulation
DAST-Tools simulieren Angriffe aus der realen Welt auf eine Webanwendung und ermöglichen so eine praxisnahe Bewertung ihres Sicherheitsstatus.
Beispiel aus dem realen Leben
Im Mai 2023 wurde eine SQL-Injection-Schwachstelle in der weit verbreiteten MOVEit Transfer-Plattform von Progress Software ausgenutzt, bevor der Hersteller davon Kenntnis erlangte. Der Sicherheitsvorfall kompromittierte 11,3 Millionen Patientendatensätze bei Maximus und betraf Dutzende von Regierungsbehörden und Unternehmen in mehreren Ländern, darunter die BBC, das britische HR-Softwareunternehmen Zellis und die Regierung von Nova Scotia. 3
Progress Software erfuhr erst von der Sicherheitslücke, als diese bereits aktiv ausgenutzt wurde. Das Unternehmen bestätigte die Schwachstelle, veröffentlichte einen Patch und informierte die Kunden noch am selben Tag, doch die Ausnutzung hatte bereits vor der Bekanntgabe begonnen. 4
Ein DAST-Scanner, der in einer Testumgebung gegen die Webanwendung von MOVEit ausgeführt wurde, hätte SQL-Injection-Payloads an die Eingabefelder der Anwendung gesendet und die anomale Datenbankantwort – dieselbe Technik, die Angreifer verwendet haben – erkannt. Ab diesem Zeitpunkt ist die Behebung eine Entwicklungsaufgabe. Ohne diesen Test blieb derselbe Fehler in einem Produktivsystem bestehen, das von Hunderten von Organisationen genutzt wird.
3. Einhaltung von Vorschriften und regulatorischen Anforderungen
Vorschriften wie PCI DSS, HIPAA und DSGVO schreiben regelmäßige Sicherheitstests für Anwendungen vor, die sensible Daten verarbeiten. Entscheidend ist der Nachweis: Prüfer benötigen dokumentierte Belege dafür, dass Schwachstellen gefunden und behoben wurden, nicht nur die Bestätigung, dass Tests durchgeführt wurden. DAST liefert genau diese Belege: Scanberichte zeigen, welche Schwachstellen in der Live-Anwendung vorhanden waren, wann sie entdeckt wurden und ob die Behebung verifiziert wurde.
- Organisationen müssen öffentlich zugängliche Webanwendungen durch regelmäßige Schwachstellenanalysen oder eine Web Application Firewall (WAF) schützen. DAST erfüllt diese Analyseoption, indem es die bereitgestellte Anwendung auf die von Prüfern gesuchten Angriffsvektoren testet, darunter SQL-Injection, XSS und Authentifizierungsfehler, und zeitgestempelte, prüfbereite Ergebnisse generiert.
- Organisationen müssen wöchentlich automatisierte Prüfungen auf unautorisierte Änderungen an den Skripten und HTTP-Headern von Zahlungsseiten durchführen. DAST-Scanberichte unterstützen dies, indem sie kontinuierlich Nachweise auf Anwendungsebene liefern, dass die gesamte Umgebung der Zahlungsseiten nicht kompromittiert wurde.
Beispiel aus dem realen Leben
Channel 4, der öffentlich-rechtliche britische Privatsender, betreibt die Streaming-Plattform All 4 mit 24 Millionen registrierten Nutzern, die alle den Datenschutzbestimmungen der DSGVO unterliegen. Um die Einhaltung der Vorschriften nachzuweisen, beauftragte das Sicherheitsteam zuvor mehrere externe Penetrationstests pro Projekt. Jeder Test lieferte Schwachstellen, die das Team behob und anschließend einen erneuten Test in Auftrag gab. CISO Brian Brackenborough beschrieb die sich summierenden Kosten: Je nach Komplexität konnte jedes Projekt mehrere Zyklen durchlaufen.
Nach der Integration der automatisierten DAST-Plattform von Invicti stellte Channel 4 auf kontinuierliches Scannen zu festgelegten Projektmeilensteinen um und ersetzte den Wiederholungstestzyklus durch eine interne automatisierte Verifizierung. Die jährlichen Ausgaben für Penetrationstests sanken im ersten Jahr um etwa 60 % und im zweiten Jahr auf rund 20 % der ursprünglichen Ausgaben. 5
4. Umfassende Abdeckung
DAST testet jede Schnittstelle, die die Anwendung externen Anmeldeformularen, Sitzungstoken, API-Endpunkten, URL-Parametern und HTTP-Headern zugänglich macht, ohne Zugriff auf den Quellcode zu haben. Fehlerhafte Authentifizierung, Sitzungsfixierung, unsichere direkte Objektverweise und falsch konfigurierte Zugriffskontrollen existieren nicht als statische Muster im Code; sie entstehen vielmehr durch das Verhalten der Anwendung, wenn ein Benutzer oder ein Angreifer bestimmte Eingaben sendet.
DAST erfasst Endpunkte, die Entwickler möglicherweise nicht absichtlich freigegeben haben. Schatten-APIs, veraltete Routen, die nach einer Funktionsänderung noch aktiv sind, und über das öffentliche Netzwerk erreichbare Administrationsschnittstellen werden bei einer Codeüberprüfung nicht angezeigt, jedoch bei einem DAST-Crawl.
5. Kontinuierliche Überwachung
Anwendungen bleiben nach der Bereitstellung nicht statisch. Bibliotheken werden aktualisiert, neue Endpunkte hinzugefügt, Konfigurationsänderungen vorgenommen und Skripte von Drittanbietern von externen Domains geladen. Jede dieser Maßnahmen kann eine Schwachstelle einführen, die beim letzten Scan noch nicht vorhanden war. Jährliche oder vierteljährliche Tests können einen Fehler, der bei einer Bereitstellung am Dienstag entstanden ist, nicht aufdecken. DAST, integriert in eine CI/CD-Pipeline, wird bei jedem neuen Build ausgeführt. Das bedeutet, dass der Sicherheitsstatus der Anwendung kontinuierlich und nicht nur periodisch überprüft wird.
Abhängigkeiten von Drittanbietern machen dies besonders wichtig. Lieferkettenangriffe, bei denen eine vertrauenswürdige externe Komponente kompromittiert und dazu missbraucht wird, schädliches Verhalten in nachgelagerte Anwendungen einzuschleusen, zählen laut OWASP Top 10:2025 mittlerweile zu den drittgrößten Risiken für Webanwendungen. DAST erkennt diese Angriffe zur Laufzeit, wo das eingeschleuste Verhalten tatsächlich auftritt, und nicht im Quellcode, wo die Abhängigkeit möglicherweise unverändert erscheint.
Beispiel aus dem realen Leben
Im Juni 2024 wurden die Domain und das GitHub-Repository von Polyfill.js von einem neuen Eigentümer erworben, der das Skript so veränderte, dass mobile Nutzer auf schädliche Webseiten umgeleitet wurden. Über 100.000 Webanwendungen luden Polyfill direkt vom CDN, wodurch eine vertrauenswürdige Abhängigkeit unbemerkt zu einem Einfallstor für Angriffe wurde, ohne dass der Code dieser Anwendungen selbst verändert wurde. DAST-Tools erkannten das schädliche Verhalten kurz nach Bekanntwerden, identifizierten die Anwendungen, die das kompromittierte Skript luden, und generierten konkrete Handlungsempfehlungen zur Behebung des Problems. 6
6. Identifizierung von Laufzeitproblemen
Manche Schwachstellen existieren nicht im Quellcode, sondern entstehen durch das Verhalten einer im Einsatz befindlichen Anwendung unter realen Bedingungen. Race Conditions treten auf, wenn gleichzeitig mehrere Anfragen auf dieselbe Ressource zugreifen. Fehler in der Geschäftslogik werden sichtbar, wenn ein Angreifer einen mehrstufigen Workflow in der falschen Reihenfolge durchläuft. Serverseitige Anforderungsfälschung (SSRF) manifestiert sich nur, wenn die Anwendung aktiv ausgehende Verbindungen zu anderen Systemen herstellt. Speicherlecks, Sitzungs-Timeout-Fehler und unsichere Deserialisierung erfordern eine laufende Anwendung, um ausgelöst zu werden.
DAST begegnet diesen Problemen, indem es mit der Anwendung genau so interagiert, wie es ein Benutzer oder Angreifer tun würde: Es sendet Eingaben, beobachtet die Reaktionen und testet, wie sich das System unter Bedingungen verhält, die eine statische Analyse nicht simulieren kann.
7. Ergänzung zu anderen Testmethoden
Keine einzelne Testmethode deckt die gesamte Angriffsfläche einer modernen Anwendung ab. Sicherheitsteams kombinieren DAST typischerweise mit:
- SAST scannt den Quellcode vor der Bereitstellung und erkennt Probleme wie fest codierte Geheimnisse, unsichere Funktionsaufrufe und anfällige Stringverkettungen frühzeitig in der Entwicklung. Das Laufzeitverhalten kann damit nicht getestet werden.
- IAST instrumentiert die Anwendung während der Ausführung von innen heraus und überwacht den Datenfluss durch den laufenden Code. Während DAST das externe Verhalten der Anwendung beobachtet, beobachtet IAST ihr internes Verhalten während derselben Anfrage. Die beiden Methoden liefern komplementäre Erkenntnisse aus entgegengesetzten Perspektiven.
- SCA scannt Drittanbieter- und Open-Source-Bibliotheken auf bekannte CVEs und kennzeichnet anfällige Abhängigkeiten, bevor diese produktiv eingesetzt werden. Der Polyfill-Vorfall verdeutlicht die Lücke: SCA hätte den Angriff nicht erkannt, da die Bibliothek selbst zum Zeitpunkt der Kompromittierung der zugehörigen Domain keine CVE aufwies. DAST hingegen erkannte das schädliche Laufzeitverhalten, das SCA verborgen blieb.
- Netzwerk- und Schwachstellenscanner identifizieren offene Ports, veraltete Dienste und Fehlkonfigurationen der Infrastruktur auf der Host- und Netzwerkebene, also unterhalb der Anwendung selbst.
Einschränkungen, die Sie bei der Verwendung von DAST berücksichtigen sollten
1. Keine Einsicht in den internen Code
DAST prüft die von der Anwendung bereitgestellten Endpunkte, Formulare, Header und Antworten. Da DAST den Quellcode nicht lesen kann, bleiben Schwachstellen, die sich nicht durch externe Interaktion bemerkbar machen, unentdeckt. Beispielsweise werden fest codierte Anmeldeinformationen, die in serverseitiger Logik verborgen sind, bei einem DAST-Scan nur dann angezeigt, wenn sie eine beobachtbare Antwort erzeugen. Um solche Schwachstellen aufzuspüren, sind SAST oder eine Code-Überprüfung erforderlich.
2. Spätphasen-Entdeckung
DAST benötigt eine laufende Anwendung und kann daher erst in der Test- oder Staging-Phase eingesetzt werden. Eine früh in der Entwicklung eingeführte Schwachstelle kann mehrere Build-Zyklen überdauern, bevor sie von einem DAST-Scan entdeckt wird. Je später eine Schwachstelle gefunden wird, desto mehr Code wurde bereits darauf aufgebaut, was sowohl die Kosten für die Behebung als auch das Risiko erhöht, dass eine Korrektur neue Probleme verursacht.
3. Falsch-Positive und Falsch-Negative Ergebnisse
DAST-Tools leiten Schwachstellen aus Anwendungsantworten ab. Das bedeutet, dass sie harmloses Verhalten fälschlicherweise als Schwachstelle einstufen können (falsch-positiv) oder eine Schwachstelle, die eine bestimmte Eingabefolge erfordert, nicht erkennen (falsch-negativ). Falsch-positive Ergebnisse verschwenden Zeit bei der Behebung; falsch-negative Ergebnisse erzeugen falsche Sicherheit. Moderne Tools reduzieren falsch-positive Ergebnisse durch beweisbasierte Scans, die die Ausnutzbarkeit einer Schwachstelle bestätigen, bevor sie diese melden. Dennoch bestehen weiterhin Lücken in der Abdeckung, insbesondere in komplexen, authentifizierten Arbeitsabläufen.
4. Fehler in der Geschäftslogik
DAST identifiziert Schwachstellen, die zu erkennbaren Anomalien wie SQL-Injection, XSS und Authentifizierungs-Bypass führen. Es kann jedoch keine Fehler erkennen, bei denen sich die Anwendung zwar wie programmiert verhält, die Logik selbst aber unsicher ist. Ab 2026 stellen Broken Object Level Authorization (BOLA) und Broken Function Level Authorization (BFLA) die größten API-Sicherheitsrisiken dar; in beiden Fällen verarbeitet die Anwendung eine Anfrage korrekt, die sie eigentlich ablehnen sollte. Kein automatisierter Scanner kann feststellen, ob eine Geschäftsregel fehlerhaft ist, sondern nur, ob sie verletzt wurde.
5. Risiko der Produktionsprüfung
DAST sendet aktiv Angriffs-Payloads an eine laufende Anwendung. In der Testumgebung ist dies das beabsichtigte Verhalten. In der Produktionsumgebung kann derselbe Scan jedoch Fehlerzustände auslösen, Testdaten beschädigen, Benutzerkonten sperren oder eine Last erzeugen, die die Leistung für echte Benutzer beeinträchtigt. Die meisten Teams beschränken vollständige DAST-Scans auf Vorproduktionsumgebungen und verwenden in der Produktionsumgebung eine weniger restriktive, passive Überwachung, wobei sie eine geringere Abdeckung zugunsten der Betriebssicherheit in Kauf nehmen.
6. Keine Lokalisierung auf Codeebene
DAST erkennt zwar eine Schwachstelle an einem bestimmten Endpunkt, kann aber die verantwortliche Codezeile nicht lokalisieren. Entwickler, die einen DAST-Befund erhalten, müssen das Problem reproduzieren, die Anfrage durch den Anwendungsstack verfolgen und die Quelle manuell finden. Die Integration der DAST-Ausgabe mit SAST-Ergebnissen oder die Verwendung von IAST, das die Anwendung von innen instrumentiert, kann diese Lücke schließen, indem der Laufzeitbefund mit einer Codestelle korreliert wird.
7. Abdeckungslücken in modernen Anwendungsarchitekturen
DAST durchsucht eine Anwendung, indem es Links folgt und Formulare absendet. Single-Page-Anwendungen, die auf React, Angular oder Vue basieren, rendern Inhalte nach dem ersten Seitenaufruf dynamisch per JavaScript. Herkömmliche Crawler können diese Bereiche nicht vollständig erfassen. APIs, die spezielle Authentifizierungstoken, mehrstufige Workflows oder nicht standardisierte Eingabeformate erfordern, bleiben möglicherweise ebenfalls ungetestet, sofern DAST nicht explizit dafür konfiguriert ist. Die Abdeckung ist nur so vollständig wie die Fähigkeit des Scanners, in der Anwendung zu navigieren.
FAQs
Dynamische Anwendungssicherheitstests (DAST) prüfen eine laufende Anwendung von außen nach innen, ohne Zugriff auf den Quellcode. Sie senden schädliche Eingaben, SQL-Injection-Payloads, XSS-Strings und Versuche, die Authentifizierung zu umgehen, an exponierte Schnittstellen und kennzeichnen unerwartete Antworten als potenzielle Schwachstellen. Da DAST exakt wie ein externer Angreifer vorgeht, findet es Fehler, die erst zur Laufzeit auftreten und durch statische Codeanalyse nicht erkannt werden können.
In modernen Softwareentwicklungsmethoden, insbesondere solchen, die DevOps-Ansätze verfolgen, lassen sich DAST-Best Practices und DAST-Tools in CI/CD-Pipelines (Continuous Integration/Continuous Deployment) integrieren. Diese Integration gewährleistet die kontinuierliche Sicherheit während des gesamten Anwendungslebenszyklus.
Um ein DAST-Tool auszuwählen, besuchen Sie die Liste der besten DAST-Lösungen .
DAST-Tools, Tools zum Scannen von Schwachstellen, API-Sicherheitstools und Tools zur Anwendungssicherheit dienen spezifischen Zwecken im breiteren Kontext der Cybersicherheit, obwohl es einige Überschneidungen gibt.
DAST-Tools sind darauf spezialisiert, die Sicherheit von Webanwendungen während des Betriebs zu testen, indem sie externe Angriffe simulieren, um Schwachstellen aufzudecken, die erst während des Betriebs sichtbar werden.
Tools zum Scannen von Schwachstellen bieten einen umfassenderen Service, indem sie Systeme, Netzwerke oder Anwendungen auf eine Vielzahl von Sicherheitsproblemen scannen, einschließlich Schwachstellen, die sich nicht nur auf die Software selbst beschränken, sondern auch Konfigurationen oder veraltete Systeme betreffen können.
API-Sicherheitstools wurden speziell zum Schutz von APIs entwickelt, die als kritische Schnittstellen zwischen verschiedenen Softwareanwendungen fungieren. Diese Tools konzentrieren sich auf API-spezifische Sicherheitsaspekte, wie die Absicherung von Endpunkten, die Authentifizierung und Verwaltung von API-Aufrufen sowie die Gewährleistung der Datenintegrität während der Übertragung.
Anwendungssicherheitstools umfassen ein breites Spektrum an Werkzeugen, darunter die oben genannten Typen, und zielen darauf ab, Anwendungen während ihres gesamten Lebenszyklus zu schützen. Diese Kategorie beinhaltet Werkzeuge und Verfahren, die die Sicherheit in verschiedenen Phasen – von der Entwicklung über die Bereitstellung bis hin zur Wartung – gewährleisten.
Diese Kategorien überschneiden sich jedoch:
DAST-Tools sind eine Untergruppe der Anwendungssicherheitstools, die speziell darauf abzielen, Schwachstellen in laufenden Webanwendungen durch simulierte externe Angriffe zu identifizieren.
API-Sicherheitstools fallen zwar auch unter den Oberbegriff Anwendungssicherheitstools, konzentrieren sich aber speziell auf die Sicherheit von API-Schnittstellen und gehen dabei auf besondere Herausforderungen wie Endpunktsicherheit und Authentifizierung ein.
Tools zum Scannen von Schwachstellen haben einen breiteren Anwendungsbereich und umfassen Sicherheitsprüfungen ganzer Systeme, einschließlich Netzwerken und Anwendungen. Sie bieten häufig Funktionen zur Identifizierung von Schwachstellen in Webanwendungen und APIs und überschneiden sich daher mit DAST- und API-Sicherheitstools.
Referenzlinks
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich.