DAST (Dynamic Application Security Testing).

DAST-Tools interagieren mit einer deployten Anwendung – typischerweise über HTTP – ohne Quellcode zu benötigen. Sie crawlen Endpunkte, senden manipulierte Requests und werten Responses aus, um SQL-Injection, XSS, SSRF, fehlerhafte Authentifizierung, falsch konfiguriertes CORS oder unsichere Cookies zu erkennen. Da sie sehen, was auch ein Angreifer sieht, ergänzt DAST SAST und findet Probleme, die nur zur Laufzeit auftreten – auch durch Konfiguration, Infrastruktur oder Drittanbieter. Üblich ist der Einsatz in Staging/QA-Umgebungen und als Release-Gate in der CI/CD. Bekannte Tools: OWASP ZAP, Burp Suite, Invicti, Acunetix, StackHawk.

Funktionsweise

Ein DAST-Scan läuft in zwei Phasen ab. Zunächst kartiert ein Crawler (Spider) die Angriffsfläche der Anwendung, indem er Links folgt, JavaScript parst und aufgezeichneten Traffic erneut abspielt, um Formulare, Parameter und API-Routen zu entdecken. Anschließend mutiert ein aktiver Scanner jede Eingabe mit Angriffs-Payloads und leitet aus Antwortcodes, Timing, reflektierten Inhalten oder Fehlersignaturen auf Schwachstellen – so wird beispielsweise eine zeitbasierte Blind-SQL-Injection bestätigt, wenn ein SLEEP()-Payload die Antwort messbar verzögert.

Modernes DAST hat sich in Richtung API-first- und authentifiziertem Scannen verlagert: Single-Page-Apps und REST-/GraphQL-Backends offenbaren einem naiven Crawler nur wenig, weshalb Scanner OpenAPI-/Swagger-Spezifikationen einlesen und geskriptete Login-Sequenzen nutzen, um geschützte Funktionen zu erreichen. Die Abdeckung wird häufig gegen den OWASP Web Security Testing Guide (WSTG) abgebildet. Ebenso wichtig sind die Grenzen von DAST: Es liefert keine Position auf Codezeilen-Ebene, kann nicht erreichbare Codepfade nicht sehen und riskiert False Negatives bei komplexem clientseitigem State – deshalb kombinieren Teams es mit SAST und IAST, statt sich allein darauf zu verlassen. Um das Scannen der Produktion und das Auslösen echter Nebenwirkungen (Versand von E-Mails, Aufgabe von Bestellungen) zu vermeiden, werden Scans auf Nicht-Produktionsziele beschränkt und mit einem definierten Scope sowie einer Ausschlussliste versehen.

flowchart LR
  A[Laufende App<br/>Staging/QA] --> B[Crawler / Spider<br/>kartiert Endpunkte]
  B --> C[Aktiver Scanner<br/>injiziert Payloads]
  C --> D{Anomalie in<br/>der Antwort?}
  D -->|Ja| E[Fund melden<br/>SQLi / XSS / SSRF]
  D -->|Nein| F[Endpunkt als sauber markieren]
  E --> G[CI/CD-Gate<br/>Build abbrechen / triagieren]