Schwachstellen-Scanner

Das Problem

Sicherheitsluecken verstecken sich vor aller Augen. SQL Injection in einem Query Builder, XSS in einem Template Literal, fehlerhafte Authentifizierung in einer Middleware — diese Schwaechen passieren Code Reviews, weil Reviewer auf Funktionalitaet achten, nicht auf Ausnutzbarkeit. Man braucht einen dedizierten Sicherheitsdurchlauf, der wie ein Angreifer denkt, nicht wie ein Feature-Entwickler.

Der Prompt

Du bist ein erfahrener Application-Security-Engineer. Fuehre ein Sicherheitsaudit des folgenden Codes durch und denke dabei wie ein Angreifer, der ihn ausnutzen will.

SPRACHE/FRAMEWORK: [z.B. Node.js/Express, Python/Django, PHP/Laravel]
ANWENDUNGSTYP: [z.B. REST API, Webanwendung mit Auth, E-Commerce]

CODE:
[Code hier einfuegen — Fokus auf Auth, Eingabeverarbeitung, Datenbankabfragen oder API-Endpunkte]

Scanne auf diese Schwachstellenkategorien (OWASP Top 10 2021):

1. **A01 — Fehlerhafte Zugriffskontrolle**: Fehlende Auth-Checks, IDOR, Rechteerweiterung
2. **A02 — Kryptografische Fehler**: Schwaches Hashing, Klartext-Secrets, unsichere Uebertragung
3. **A03 — Injection**: SQL, NoSQL, OS-Befehle, LDAP, Template Injection
4. **A04 — Unsicheres Design**: Fehlende Rate Limits, Geschaeftslogik-Luecken
5. **A05 — Sicherheitsfehlkonfiguration**: Debug-Modus, Standard-Zugangsdaten, ausufernde Fehlermeldungen
6. **A06 — Verwundbare Komponenten**: Bekannte CVEs in Abhaengigkeiten
7. **A07 — Auth-Fehler**: Schwache Passwoerter, fehlendes MFA, Session-Probleme
8. **A08 — Datenintegritaetsfehler**: Unsichere Deserialisierung, unsignierte Updates
9. **A09 — Logging-Maengel**: Fehlende Audit-Logs, sensible Daten in Logs
10. **A10 — SSRF**: Unvalidierte URLs bei serverseitigen Anfragen

Fuer jede gefundene Schwachstelle:
- **Schweregrad**: Kritisch / Hoch / Mittel / Niedrig
- **Angriffsszenario**: Wie ein Angreifer das ausnutzen wuerde
- **Betroffener Code**: Genaue Zeile oder Funktion
- **Loesung**: Sicherer Code-Ersatz

Beispielausgabe

## Sicherheitsaudit: 3 Schwachstellen gefunden

### KRITISCH: SQL Injection (A03)
Zeile 28: `db.query("SELECT * FROM orders WHERE user_id = " + req.params.id)`
Angriff: Angreifer sendet `/orders/1 OR 1=1`, um alle Bestellungen auszulesen.
Loesung: `db.query("SELECT * FROM orders WHERE user_id = $1", [req.params.id])`

### HOCH: Fehlerhafte Zugriffskontrolle (A01)
Zeile 45: `/api/users/:id`-Endpunkt hat keine Eigentuemerpruefung.
Angriff: Nutzer A kann auf Daten von Nutzer B zugreifen, indem er die ID aendert.
Loesung: `if (req.user.id !== req.params.id) return res.status(403).json({error: "Zugriff verweigert"})`

### MITTEL: Fehlendes Rate Limit (A04)
`/api/login` hat kein Rate Limiting.
Angriff: Brute-Force-Passwortversuche mit unbegrenzter Geschwindigkeit.
Loesung: express-rate-limit mit max. 5 Versuchen pro Minute pro IP hinzufuegen.

Wann verwenden

Bei jedem Authentifizierungs-Flow, API-Endpunkt oder jeder Datenbankinteraktion vor dem Deployment ausfuehren. Unverzichtbar bei der Verarbeitung von Nutzereingaben, Finanzdaten oder personenbezogenen Daten. Als Sicherheits-Gate vor PRs nutzen, die Auth, Zahlungen oder Datenzugriff betreffen.

Profi-Tipps

• Ein Thema pro Durchlauf — bei grossen Codebasen Auth-Flows getrennt von Datenzugriffsschichten scannen, um gruendlichere Ergebnisse zu erhalten.
• Middleware-Stack einbeziehen — die Auth-Middleware zusammen mit dem Route Handler einfuegen, damit die KI die gesamte Request-Kette verifizieren kann.
• Exploit-Beweis anfordern — nachfragen: “Schreibe einen curl-Befehl, der zeigt, wie die SQL Injection ausgenutzt wird”, um das reale Risiko zu verstehen.