Zum Inhalt springen

Services, Wiki-Artikel, Blog-Beiträge und Glossar-Einträge durchsuchen

↑↓NavigierenEnterÖffnenESCSchließen
DevSecOps Glossar

IAST (Interactive Application Security Testing)

Interactive Application Security Testing (IAST) kombiniert SAST und DAST: Agenten werden direkt in laufende Anwendungen injiziert und analysieren Code-Ausführung und Datenflüsse in Echtzeit während Tests ablaufen. IAST findet mehr als SAST alleine, mit weniger False Positives als DAST - und ohne separate Test-Phase.

IAST ist der “Sweet Spot” zwischen statischer und dynamischer Analyse: Ein Instrument-Agent wird in die laufende Anwendung injiziert und beobachtet von innen was passiert - welche Funktionen aufgerufen werden, wohin Daten fließen, ob User-Input ungefiltert in Datenbankabfragen landet. Das Ergebnis: präzise Findings mit exakten Code-Positionen, gefunden während reguläre Tests laufen.

SAST vs. DAST vs. IAST im Vergleich

                SAST            DAST            IAST
Zeitpunkt:      Compile-Zeit    Laufzeit        Laufzeit
Sicht:          Code (innen)    HTTP (außen)    Code + Laufzeit
Sprachen:       sprachspezif.   sprachagnostik  sprachspezifisch
False Positives: Hoch           Mittel          Niedrig
False Negatives: Mittel         Hoch            Niedrig
Deployment:     CI/CD           Staging         Test-Umgebung

SAST findet:    Syntaktische Muster im Code
DAST findet:    HTTP-Responses auf Angriffs-Payloads
IAST findet:    Tatsächliche Datenflüsse zur Laufzeit

Beispiel SQL-Injection:
  SAST: "Zeile 47: String-Konkatenation in DB-Query - verdächtig"
        → Aber: ist es wirklich User-Input? False Positive möglich!

  DAST: "POST /search mit ' erzeugt 500 Internal Server Error"
        → Erkennt Symptom, kennt Code-Zeile nicht

  IAST: "Zeile 47, Funktion searchProducts(): User-Input aus
         request.query.term fließt ohne Sanitization in
         SQL-Statement - CONFIRMED SQL-Injection"
        → Exakte Zeile, bestätigter Datenfluss, kein False Positive!

IAST-Tools und Integration

Führende IAST-Lösungen:

Contrast Security (Marktführer):
  → Agenten für Java, .NET, Node.js, Python, Ruby, Go, PHP
  → Kontinuierliche Analyse während Funktionaltests
  → Automatically creates tickets in Jira/ServiceNow
  → Integration in CI/CD-Pipeline als Test-Phase

Seeker (Synopsys):
  → Tief in Java/J2EE integriert
  → Gut für Legacy Java-Enterprise-Apps
  → DAST-Erweiterung verfügbar

HCL AppScan IAST:
  → Enterprise-Fokus, IBM-Erbe
  → SAP/Oracle Integration

---

Java-Agent Integration (Beispiel Contrast):

  Maven Surefire Plugin (Unit Tests):
  Die JAR wird als Java-Agent beim Test-Start geladen:
    -javaagent:/path/to/contrast.jar
    -Dcontrast.standalone.appname=MyApp
    -Dcontrast.server.name=CI-Server
    -Dcontrast.api.key=${CONTRAST_API_KEY}

  Spring Boot direkt starten:
  java -javaagent:contrast.jar
    -Dcontrast.standalone.appname=MyApp
    -jar myapp.jar

  Node.js Agent (Contrast):
  In package.json scripts:
    "test:security": "node -r @contrast/agent ./node_modules/.bin/jest"

---

IAST in GitLab CI:
  iast_test:
    stage: test
    image: openjdk:17
    variables:
      CONTRAST_API_KEY: "${CONTRAST_API_KEY}"
      CONTRAST_SERVICE_KEY: "${CONTRAST_SERVICE_KEY}"
    script:
      - wget -q https://app.contrastsecurity.com/Contrast/api/agent/java -O contrast.jar
      - mvn test -DargLine="-javaagent:contrast.jar -Dcontrast.appname=$CI_PROJECT_NAME"
    artifacts:
      reports:
        sast: contrast-findings.json

Was IAST erkennt

OWASP Top 10 Detection durch IAST:

A01 Broken Access Control:
  → IDOR: User A ruft Ressource von User B ab - IAST sieht fehlende Auth-Check!
  → Path Traversal: ../../../etc/passwd in Dateizugriff

A02 Cryptographic Failures:
  → MD5/SHA1 für Passwort-Hashing → IAST erkennt schwachen Hash-Algorithmus
  → Sensible Daten in Logs: IAST verfolgt Datenfluss

A03 Injection:
  → SQL Injection: User-Input direkt in Datenbankabfrage? IAST sieht es!
  → Command Injection: user-input → Betriebssystemaufruf
  → XSS: unescapter Output in HTML-Template

A04 Insecure Design:
  → Business Logic Flaws (schwerer zu automatisieren)

A05 Security Misconfiguration:
  → CORS: zu permissive Konfiguration erkannt
  → Security Headers: X-Frame-Options, CSP fehlen

A08 Software and Data Integrity:
  → Deserialization: ObjectInputStream mit externem Input ohne Validierung

IAST vs. RASP - Erkennen vs. Schützen

RASP (Runtime Application Self-Protection):
  → Schützt Produktion in Echtzeit (nicht nur Test-Phase!)
  → Blockiert Angriffe wenn sie erkannt werden
  → Kein separater Test nötig: läuft immer mit

IAST:
  → Test-Umgebung: analysiert und meldet, blockiert nicht
  → Development/Staging-Phase

Beide kombiniert (Contrast Security):
  → IAST in Test → Findings gefunden und gefixt
  → RASP in Produktion → Resilienz gegen unbekannte Angriffe

RASP-Aktion bei erkanntem Angriff:
  1. Monitor: nur loggen (kein Eingriff)
  2. Block: Request ablehnen + 403 zurückgeben
  3. Block + Report: ablehnen + Security-Team informieren

  Beispiel:
  SQL-Injection-Versuch → RASP erkennt in 50ms:
  → Originale Datenbankabfrage verhindert → "Access Denied"
  → SIEM-Alert innerhalb 1 Sekunde
  → Zero Impact auf legitime Nutzer

DevSecOps-Pipeline Einordnung:
  Pre-Commit: Secret Detection, Linting
  CI:         SAST, SCA, Secret Scanning
  Build:      Container Scanning
  Test:       IAST (während Integrationstests!) ← hier
  Staging:    DAST
  Produktion: RASP, WAF

Cookielose Analyse via Matomo (selbst gehostet, kein Tracking-Cookie). Datenschutzerklärung