jappel/leistungsbilanz-ts
1
0
Fork 1
Code Issues 6 Pull requests Projects Releases Packages Wiki Activity Actions
leistungsbilanz-ts/.agents/skills/authz-idor-audit/SKILL.md
Grovy311 afd8019a7b
Some checks are pending
security-baseline / secrets (push) Waiting to run
Details
security-baseline / node (push) Waiting to run
Details
security-baseline / semgrep (push) Waiting to run
Details
security-baseline / trivy (push) Waiting to run
Details
Address security review notes 
- 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>
2026-10-15 09:45:59 +02:00

3.1 KiB
Raw Blame History

name description
authz-idor-audit 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