RASP – Runtime Application Self-Protection
„Die App verteidigt sich selbst. Endlich!"
Sinn & Zweck
RASP ist Security, die direkt in der Anwendung lebt – nicht davor, nicht danach, sondern mittendrin. Während WAF vor der App steht und SAST den Code vor dem Deployment analysiert, läuft RASP in der Anwendung und beobachtet, was zur Laufzeit wirklich passiert.
Die Idee: Wenn die Anwendung selbst weiß, was ein Angriff ist, kann sie sich sofort verteidigen – ohne auf externe Systeme zu warten.
Traditionell:
Request → WAF → App → "Oh nein, SQL Injection!" → zu spät
Mit RASP:
Request → App + RASP → "SQL Injection erkannt!" → BLOCK → Log → Response
Wie RASP funktioniert
Instrumentierung
RASP injiziert Sensoren in die Anwendung:
┌────────────────────────────────────────────────────────┐
│ Anwendung │
│ ┌─────────────────────────────────────────────────┐ │
│ │ RASP Agent │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ HTTP Handler│ │ SQL Handler │ │ │
│ │ │ Sensor │ │ Sensor │ │ │
│ │ └──────┬──────┘ └──────┬──────┘ │ │
│ │ │ │ │ │
│ │ ┌──────┴────────────────┴──────┐ │ │
│ │ │ Threat Detection │ │ │
│ │ │ Engine │ │ │
│ │ └───────────────┬───────────────┘ │ │
│ │ │ │ │
│ │ ┌─────────┴─────────┐ │ │
│ │ ↓ ↓ │ │
│ │ ┌─────────┐ ┌─────────┐ │ │
│ │ │ BLOCK │ │ LOG │ │ │
│ │ └─────────┘ └─────────┘ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌────────────┐ │
│ │ Controller │───→│ Service │───→│ Repository │ │
│ └─────────────┘ └─────────────┘ └────────────┘ │
└────────────────────────────────────────────────────────┘
Erkennungspunkte
RASP überwacht kritische Operationen:
| Punkt | Was wird überwacht | Angriffe erkannt |
|---|---|---|
| HTTP Input | Requests, Headers, Parameters | XSS, Injection |
| SQL Execution | Queries, Parameters | SQL Injection |
| File Operations | Read, Write, Path | Path Traversal, LFI |
| Command Execution | Shell Commands | Command Injection |
| Deserialization | Object Streams | Insecure Deserialization |
| LDAP Queries | Search Filters | LDAP Injection |
| XML Parsing | DTD, Entities | XXE |
| Network | Outbound Connections | SSRF |
RASP vs. WAF vs. IAST
Request Flow
│
↓
┌─────────────┐
│ WAF │ ← Analysiert HTTP-Traffic (Patterns)
│ (Perimeter) │ Kein App-Kontext
└──────┬──────┘
│
↓
┌─────────────┐
│ Load │
│ Balancer │
└──────┬──────┘
│
↓
┌────────────────────────────────────────┐
│ Application │
│ ┌──────────────────────────────────┐ │
│ │ RASP │ │ ← Im App-Kontext
│ │ (Weiß was Code macht) │ │ Sieht echte Angriffe
│ └──────────────────────────────────┘ │
│ ┌──────────────────────────────────┐ │
│ │ IAST │ │ ← Für Testing, nicht Prod
│ │ (Nur in Test-Environments) │ │ Findet Vulnerabilities
│ └──────────────────────────────────┘ │
└────────────────────────────────────────┘
| Aspekt | WAF | RASP | IAST |
|---|---|---|---|
| Position | Vor der App | In der App | In der App |
| Kontext | HTTP only | Voller App-Kontext | Voller App-Kontext |
| Modus | Blocking | Blocking/Monitoring | Nur Monitoring |
| Environment | Prod | Prod | Test only |
| False Positives | Viele | Wenige | Wenige |
| Performance | Minimal | Spürbar | Spürbar |
RASP-Produkte
Commercial
| Produkt | Sprachen | Anmerkung |
|---|---|---|
| Contrast Protect | Java, .NET, Node, Python, Go | Marktführer, IAST + RASP |
| Imperva RASP | Java, .NET | Fokus auf Enterprise |
| Signal Sciences (Fastly) | Multi | Jetzt Teil von Fastly |
| Hdiv | Java, .NET | EU-basiert |
| Sqreen (acquired) | Python, Node, Ruby, Go | Jetzt Teil von Datadog |
Open Source
| Produkt | Sprachen | Status |
|---|---|---|
| OpenRASP (Baidu) | Java, PHP | Aktiv, limitiert |
| OWASP AppSensor | Konzept/Java | Reference Implementation |
Implementation
Java (Contrast Protect Beispiel)
# Agent als JVM-Parameter
java -javaagent:/path/to/contrast.jar \
-Dcontrast.mode=protect \
-Dcontrast.server.name=prod-server-1 \
-jar myapp.jar
.NET
<!-- web.config -->
<configuration>
<system.webServer>
<modules>
<add name="ContrastModule"
type="Contrast.NET.Module, ContrastAgent" />
</modules>
</system.webServer>
</configuration>
Node.js
// Ganz am Anfang der App
require('@contrast/agent');
// Rest der App
const express = require('express');
const app = express();
// ...
Kubernetes
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
containers:
- name: app
image: myapp:latest
env:
- name: JAVA_TOOL_OPTIONS
value: "-javaagent:/contrast/contrast-agent.jar"
volumeMounts:
- name: contrast-agent
mountPath: /contrast
initContainers:
- name: contrast-init
image: contrast/agent:latest
volumeMounts:
- name: contrast-agent
mountPath: /contrast
volumes:
- name: contrast-agent
emptyDir: {}
Detection & Response Modi
Monitor Mode (Observe)
mode: monitor
behavior:
- Detect attacks
- Log everything
- Allow all requests
- No blocking
use_case:
- Initial deployment
- Learning phase
- Low-risk environments
Protect Mode (Block)
mode: protect
behavior:
- Detect attacks
- Block malicious requests
- Return error response
- Alert SOC
use_case:
- Production environments
- High-risk applications
- After tuning phase
Response-Optionen
attack_detected:
actions:
- block: true
- log:
severity: critical
include: request, user, session
- alert:
channel: slack
mention: "@security-oncall"
- terminate_session: optional
- ban_ip: temporary (30 min)
Was RASP erkennt
SQL Injection
// Vulnerable Code
String query = "SELECT * FROM users WHERE id = " + userId;
// RASP sieht:
// 1. HTTP Parameter: userId = "1 OR 1=1"
// 2. SQL Query wird gebaut
// 3. User-Input erscheint unsanitiert in Query
// 4. → BLOCK!
Cross-Site Scripting (XSS)
// Vulnerable Code
res.send("Hello " + req.query.name);
// RASP sieht:
// 1. Input: name = "<script>alert(1)</script>"
// 2. Wird direkt in Response geschrieben
// 3. Keine Encoding
// 4. → BLOCK oder Encode!
Path Traversal
// Vulnerable Code
File file = new File("/uploads/" + filename);
// RASP sieht:
// 1. filename = "../../../etc/passwd"
// 2. File-Operation außerhalb erlaubtem Pfad
// 3. → BLOCK!
SSRF
# Vulnerable Code
response = requests.get(user_provided_url)
# RASP sieht:
# 1. Outbound request zu: http://169.254.169.254/
# 2. AWS Metadata Service!
# 3. → BLOCK!
Risiken & Grenzen
Performance Overhead
Ohne RASP: Response Time = 50ms
Mit RASP: Response Time = 55-65ms (10-30% Overhead)
In latency-kritischen Anwendungen problematisch.
Sprachunterstützung
| Sprache | Support |
|---|---|
| Java | Excellent |
| .NET | Gut |
| Node.js | Gut |
| Python | Mittel |
| Go | Wachsend |
| Ruby | Limitiert |
| PHP | Limitiert |
| Rust | Kaum |
Vendor Lock-in
RASP tief in die App integriert = schwer zu wechseln.
Nicht alle Angriffe
RASP ist blind für:
- Business Logic Flaws
- Authentication Bypasses (manche)
- Authorization Issues
- Cryptographic Weaknesses
False Positives (seltener, aber möglich)
Legitimer Request: POST /api/code
Body: "SELECT * FROM users" (Code-Beispiel in Tutorial)
RASP: "SQL INJECTION!"
Reality: Markdown-Content für Blog
Vorteile
Kontextbewusstsein
WAF sieht: "SELECT" in Parameter → Block (maybe false positive)
RASP sieht:
- "SELECT" in Parameter
- Parameter wird in SQL-Query verwendet
- Query wird an DB gesendet
- → Definitiv SQL Injection!
Keine Pattern-Umgehung
WAF-Bypass-Techniken funktionieren nicht:
WAF: "Hmm, 'SEL'+'ECT' sieht harmlos aus..."
RASP: "Der finale SQL-Query ist SELECT * FROM... → BLOCK"
Virtuelle Patches
Vulnerability gefunden, aber Fix dauert?
# RASP Virtual Patch
virtual_patch:
vulnerability: CVE-2024-1234
affected_endpoint: /api/vulnerable
action: block
until: fix_deployed
Developer Feedback
RASP Alert:
"SQL Injection in UserController.java:47
Input: request.getParameter("id")
Vulnerable Query: "SELECT * FROM users WHERE id = " + id
Fix: Use PreparedStatement"
Best Practices
1. Start im Monitor Mode
# Woche 1-4: Nur beobachten
mode: monitor
log_level: verbose
# Danach: False Positives tunen
# Dann: Protect Mode aktivieren
2. Schrittweise ausrollen
Phase 1: Dev/Test Environments
Phase 2: Staging
Phase 3: Prod (Monitor)
Phase 4: Prod (Protect)
3. Mit Entwicklern arbeiten
RASP-Alerts sind Goldgruben für Security Training:
- Konkrete Vulnerabilities
- Exakte Code-Stellen
- Real-World Exploitation
4. Alerting integrieren
integrations:
siem: splunk
ticketing: jira
chat: slack
alert_routing:
critical: page_oncall
high: slack_channel
medium: jira_ticket
low: daily_digest
5. Performance monitoren
monitoring:
latency_baseline: 50ms
latency_threshold: 75ms # 50% increase
alerts:
if: latency > threshold
then: investigate_rasp_impact
RASP + Defense in Depth
┌─────────────────────────────────────────────────────────┐
│ Defense Layers │
├─────────────────────────────────────────────────────────┤
│ ┌─────────────────────────────────────────────────┐ │
│ │ Layer 1: WAF (Perimeter) │ │
│ │ - Known attack patterns │ │
│ │ - Bot protection │ │
│ │ - Rate limiting │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Layer 2: RASP (Application) │ │
│ │ - Context-aware detection │ │
│ │ - Zero false positives (fast) │ │
│ │ - Virtual patching │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Layer 3: Secure Code (Foundation) │ │
│ │ - Parameterized queries │ │
│ │ - Input validation │ │
│ │ - Output encoding │ │
│ └─────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
Fazit
RASP ist die letzte Verteidigungslinie direkt in der Anwendung. Es ersetzt weder WAF noch sichere Codierung, aber es fängt ab, was durchrutscht – mit dem Kontextwissen, das nur die Anwendung selbst hat.
Der Performance-Overhead ist real, aber in den meisten Fällen akzeptabel. Für kritische Anwendungen ist RASP eine sinnvolle Ergänzung der Security-Architektur.
Eine App mit RASP ist wie ein Kampfsportler: Selbst wenn du reinkommst, musst du mit Gegenwehr rechnen.
Weiterführende Ressourcen: