Befund der Pentesterin. updateUser machte deleteMany + createMany ohne
Transaktion und ohne skipDuplicates. Eine doppelte roleId ([4,4]) oder
eine erfundene ([99999]) kam durch die Teilmengenregel - sie bringt keine
Rechte mit, faellt dort also nicht auf - und schlug erst beim Schreiben
fehl, nach dem Loeschen. Antwort HTTP 400, Konto danach ohne jede Rolle.
Die Antwort log ueber sich selbst: "400" liest sich als abgelehnt, nichts
passiert. Zerstoert wurde trotzdem.
Damit war die Letzter-Admin-Sperre umgangen, ohne sie anzugreifen: Sie
prueft die Absicht (die Admin-Rolle steht im Body, also "bleibt Admin"),
der Schreibvorgang scheiterte danach. Aussperrung, Rueckweg nur per CLI.
Auch versehentlich ausloesbar durch doppelte IDs aus dem Frontend.
Es war meine eigene Haertung, die ich nicht mitgenommen habe: updateRole
hatte Dedup und skipDuplicates seit Etappe 1, das Geschwister
updateUser/createUser nicht. Genau das Muster, das in derselben Runde
dreimal aufgeraeumt wurde - eine Absicherung, die nur in einer von zwei
Kopien ankommt.
normalisiereRollenIds() prueft jetzt vor jeder Entscheidung und jedem
Schreibvorgang gegen die Datenbank, dedupliziert, und der Tausch laeuft
in einer Transaktion. Die Letzter-Admin-Sperre arbeitet damit auf einer
Liste, die auch einloesbar ist.
Nebenbefund beim Nachstellen: Die rohe Prisma-Fehlermeldung ging
wortwoertlich an den Client, inklusive Dateipfad des Servers. Wird jetzt
protokolliert statt ausgeliefert.
Nachgestellt: [22,22] -> 200 mit erhaltener Rolle; [99999] und
[22,99999] -> 400 mit Rollen unveraendert; [-1] -> 400; [22,23] -> 200
korrekt gesetzt. createUser ebenso, abgelehnte Anlagen hinterlassen kein
Konto.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
duffyduckandClaude Opus 5
b2963be482