afd8019a7b
- log only the error name for rejected 4xx requests (JSON.parse messages can quote the request body, e.g. a password) - refuse LB_DATABASE_PATH in production; it is test-only - fix two stale file references in the skill texts Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
65 lines
3.1 KiB
Markdown
65 lines
3.1 KiB
Markdown
---
|
|
name: authz-idor-audit
|
|
description: >
|
|
Autorisierung einer App systematisch prüfen: Rollenmatrix aufstellen, jede Route gegen
|
|
Rollen und Objektbesitz abgleichen, IDOR- und Rechte-Lücken finden und als Tests abbilden.
|
|
|
|
TRIGGER WENN der User sagt: "IDOR", "Berechtigungen prüfen", "Rollen prüfen",
|
|
"wer darf was", "Rollenmatrix", "authz audit", "/authz-idor-audit", oder wenn neue
|
|
Endpunkte, Rollenänderungen, SSO/OIDC oder Team-/Mehrbenutzer-Funktionen dazukommen.
|
|
|
|
Ergebnis: Rollenmatrix, gefundene Lücken, neue Tests (erst rot, dann grün).
|
|
---
|
|
|
|
# authz-idor-audit
|
|
|
|
Login allein schützt nichts: die häufigste Lücke in KI-Code ist „eingeloggt, aber sieht
|
|
fremde Objekte“ (IDOR). Dieser Skill macht die Rechte explizit und testbar.
|
|
|
|
## Ablauf
|
|
|
|
### 1. Routen und Rollen erfassen
|
|
- Alle Routen auflisten: FastAPI aus `app.openapi()["paths"]` (nicht aus `app.routes`,
|
|
eingebundene Router fehlen dort je nach Version), Express aus dem Routen-Inventar der
|
|
Baseline (`tests/security/route-inventory.ts`) oder per `grep -rn "router\.\(get\|post\|put\|patch\|delete\)"`.
|
|
- Rollen und Identitätsquelle aus dem Code ermitteln (Session, JWT, Proxy-Header, OIDC-Claims).
|
|
|
|
### 2. Rollenmatrix aufstellen
|
|
Pro Ressource und Aktion: wer darf? Zellen: `alle`, `eigene`, `Team`, `Admin`, `—`.
|
|
```
|
|
| Ressource | Aktion | Mitarbeiter | Projektleiter | Admin |
|
|
|----------------|--------|-------------|---------------|-------|
|
|
| Projekt | lesen | zugewiesene | eigene | alle |
|
|
| Projekt | ändern | — | eigene | alle |
|
|
| Zuweisung | anlegen| — | eigene Proj. | alle |
|
|
| Mitarbeiterdaten | lesen | sich selbst | Team | alle |
|
|
```
|
|
Unklare Zellen **nicht raten**, sondern dem User als Frage vorlegen. Die Matrix ist eine
|
|
fachliche Entscheidung.
|
|
|
|
### 3. Code gegen Matrix prüfen
|
|
Pro Route: Wo genau wird die Matrix-Zelle durchgesetzt (Datei:Zeile)? Typische Lücken:
|
|
- Objekt per ID geladen, Besitz nicht geprüft (lesen, ändern, löschen getrennt prüfen).
|
|
- Liste ungefiltert, Filter nur im Frontend.
|
|
- Fremdschlüssel im Body (`project_id`, `owner`, `leader`, `role`) wird übernommen.
|
|
- Rechte nur im UI ausgeblendet, API offen.
|
|
- Prüfung im GET vorhanden, im PATCH/DELETE vergessen.
|
|
|
|
### 4. Tests schreiben (zuerst rot)
|
|
Für jede Lücke und jede Matrix-Zelle mit Einschränkung ein Test mit **zwei** synthetischen
|
|
Nutzern derselben Rolle (A besitzt, B nicht):
|
|
- B liest/ändert/löscht Objekt von A → 403 oder 404
|
|
- Liste von B enthält kein Objekt von A
|
|
- B setzt im Body fremde `owner`/`project_id` → 403/422
|
|
Bei eingebauter Baseline: Fälle in `IDOR_CASES` bzw. `MASS_ASSIGNMENT_CASES` der
|
|
`conftest.py` / `security.config.ts` ergänzen. Test laufen lassen, **roten Lauf zeigen**,
|
|
dann Code fixen, dann grün.
|
|
|
|
### 5. Gegenprobe
|
|
Eine der neuen Prüfungen im Code kurz auskommentieren → mindestens ein Test muss rot
|
|
werden → zurücknehmen. Ohne diesen Nachweis gilt der Test als unbewiesen.
|
|
|
|
## Ausgabe
|
|
1. Rollenmatrix (mit offenen Fragen markiert)
|
|
2. Lückentabelle: `| Route | Methode | Matrix sagt | Code macht | Datei:Zeile | Prio |`
|
|
3. Liste der neuen Tests + Ergebnis roter/grüner Lauf + Gegenprobe
|