DAST (Dynamic Application Security Testing)

DAST testet Anwendungen wie ein externer Angreifer - ohne Quellcode, nur durch Interaktion mit der laufenden Anwendung. Was SAST im Code sucht, findet DAST im Live-Betrieb: falsch konfigurierte Header, unsichere Session-Verwaltung, Injection-Schwachstellen und Logikfehler, die erst im Zusammenspiel der Komponenten entstehen.

DAST vs. SAST - Ergänzung, kein Ersatz

SAST (Static Application Security Testing)

Analysiert: Quellcode, Bytecode, Binaries
Zeitpunkt: früh im Entwicklungsprozess (Shift Left)
Zugang: Code-Repository erforderlich
Findet: Unsichere Code-Muster, bekannte Bug-Klassen
Schwäche: False Positives, Runtime-Verhalten unbekannt

// Beispiel SAST-Fund: SQL-Konkatenation im Code
String query = "SELECT * FROM users WHERE id = " + userId;
// SAST: Warnung "Potentielle SQL Injection"

Analysiert: Laufende Anwendung (HTTP-Traffic)
Zeitpunkt: Staging/Pre-Prod, kontinuierlich
Zugang: Nur HTTP-Endpunkt erforderlich (kein Code!)
Findet: Echte Schwachstellen in laufender Konfiguration
Schwäche: False Negatives (nicht alle Code-Pfade erreichbar)

Beispiel DAST-Fund: Gleiche SQL Injection
Request:  GET /user?id=1' OR '1'='1
Response: 500 Error + DB-Fehlermeldung → Beweis für SQLi

IAST (Interactive)

Kombiniert beide: Instrumentation im laufenden Prozess
Sehr gute Ergebnisse, aber komplex zu integrieren

Empfehlung: SAST + DAST + manuelle Pentests für maximale Abdeckung

OWASP Top 10 - DAST-Abdeckung

A01: Broken Access Control

Testet: URL-Parameter manipulieren (IDOR): /api/invoice/1234 → /api/invoice/1235 (fremde Rechnung?)
Testet: HTTP-Verb Tampering (GET statt POST für Admin-Aktionen)

A02: Cryptographic Failures

Erkennt: HTTP statt HTTPS auf sensiblen Endpunkten
Testet: Schwache TLS-Cipher Suites (SWEET32, POODLE)
Findet: Passwörter/Tokens in URLs oder Logs

A03: Injection

SQL-Injection: ' OR 1=1--, UNION-based, Blind SQLi
OS Command Injection: ; ls -la
XPath Injection, LDAP Injection
Template Injection (SSTI): {{7*7}} → 49

A04: Insecure Design

Begrenzt detektierbar (erfordert Geschäftslogik-Verständnis)
Rate Limiting fehlt → Brute Force möglich

A05: Security Misconfiguration

HTTP Security Headers fehlen (CSP, HSTS, X-Frame-Options)
Directory Listing aktiviert
Debug-Mode aktiv (Stack Traces, Fehlermeldungen mit Details)
Default Credentials (admin/admin, admin/password)
Unnötige HTTP-Methoden (TRACE, PUT, DELETE)

A06: Vulnerable Components

Server-Header erkennen → Version → CVE-Check
Beispiel: Apache/2.4.49 → CVE-2021-41773 (Path Traversal)

A07: Authentication Failures

Brute Force Test (mit Rate Limit Check)
Session Fixation
Passwort in URL

A08: Software and Data Integrity Failures

Deserialization-Tests
CSRF-Token fehlt oder zu schwach

A09: Security Logging Failures

Schwer automatisiert testbar

A10: SSRF (Server-Side Request Forgery)

Payload: http://169.254.169.254/metadata (AWS IMDS)
Payload: http://localhost:8080/admin

DAST-Tools im Vergleich

Open Source

OWASP ZAP (Zed Attack Proxy):

Kostenlos, sehr mächtig
Aktiver und passiver Scan-Modus
CI/CD-Integration via Docker/CLI
GUI + API + CLI
Eignet sich gut für: Entwickler-Testing, CI/CD

# Basis-Scan
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t https://app.example.com -r report.html

Nikto:

Einfacher Server-Scanner
Findet: Fehlkonfigurationen, veraltete Software, Default-Files
Nicht für tiefe Anwendungstests

docker run --rm hysnsec/nikto -h https://app.example.com

Nuclei (ProjectDiscovery):

Template-basiert, extrem schnell
7000+ Templates für bekannte CVEs
Gut für: CVE-Scanning, Fehlkonfigurationen

nuclei -u https://app.example.com -t cves/,misconfiguration/

Kommerzielle Lösungen

Burp Suite Pro (PortSwigger):

Industriestandard für Pentester
Aktiver Scanner + manuelles Testing
Crawler mit Auth-Support
Kosten: ~€399/Jahr

Invicti (ehem. Netsparker):

DAST + IAST Kombination
Proof-Based Scanning (keine False Positives)
Enterprise-orientiert

Tenable.io Web App Scanning:

Integration mit Nessus-Workflow
Gut für: kombinierte Infra + App Scans

StackHawk:

Developer-first DAST
GitHub Actions / GitLab CI nativ
Gut für: DevSecOps, schnelle Feedback-Loops

DAST in der CI/CD-Pipeline

# .github/workflows/dast.yml
name: DAST Security Scan

on:
  push:
    branches: [main, develop]

jobs:
  dast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Start application
        run: docker-compose up -d

      - name: Wait for app
        run: sleep 30

      - name: ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.12.0
        with:
          target: 'http://localhost:8080'
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a'

      - name: Upload ZAP Report
        uses: actions/upload-artifact@v4
        with:
          name: zap-report
          path: report_html.html

Scan-Typen für CI/CD

Baseline Scan (schnell, ~2min):

Passiver Scan (kein aktiver Angriff)
Fehlende Security Headers, Default-Content, offensichtliche Fehler
Ideal für: jeder Push/PR

Full Scan (langsam, ~30min):

Aktiver Angriff (SQLi, XSS, SSRF, etc.)
Nur in Staging-Umgebung!
Ideal für: Release-Branches, täglicher Nachtlauf

API Scan:

OpenAPI/Swagger-Spec als Input
Testet alle API-Endpunkte automatisch

zap-api-scan.py -t openapi.yaml -f openapi

Authentifizierte DAST-Scans

Problem und Lösung

Problem: DAST ohne Auth testet nur öffentliche Seiten. Lösung: DAST mit Login-Session konfigurieren.

ZAP mit Form-Based Auth

POST /login mit username=test&password=test
ZAP merkt sich Session-Cookie / JWT-Token
Alle nachfolgenden Requests: authentifiziert

ZAP Context-Datei für komplexe Auth

contexts:
  - name: "MyApp"
    urls:
      - "https://app.example.com"
    authentication:
      method: "form"
      loginUrl: "https://app.example.com/login"
      loginRequestData: "username={%username%}&password={%password%}"
    users:
      - name: "testuser"
        credentials:
          username: "sectest@example.com"
          password: "TestPass123!"

Wichtige Hinweise

Separaten Test-Account erstellen (nie Prod-Admin!)
Test-Account mit minimalen Rechten (normaler User)
Separate Test-Umgebung (nie gegen Produktion scannen!)
Rate Limiting beachten - DAST generiert viel Traffic

DAST im SDLC einbetten

Secure Development Lifecycle

Phase	Maßnahme
Entwicklung	SAST (Echtzeit im IDE) + SAST (bei jedem Commit, CI)
Staging	DAST Baseline (bei jedem Deploy, ~2min)
Staging	DAST Full Scan (täglich, Nacht)
Staging	Manueller Pentest (quartalsweise)
Produktion	DAST passiv (Monitoring, kein aktiver Angriff)
Produktion	Externe Vulnerability Scans (monatlich)
Produktion	Bug Bounty (wenn Reife vorhanden)

Kategorisierung der Findings

Severity	Maßnahme
Critical	Sofortiger Hotfix, kein Release
High	Fix im nächsten Sprint (max. 7 Tage)
Medium	Fix im übernächsten Sprint (max. 30 Tage)
Low	Backlog, quartalsweise Review
Info	Dokumentieren, keine Fix-Pflicht

DAST vs. SAST - Ergänzung, kein Ersatz

SAST (Static Application Security Testing)