Ein API-Endpunkt bindet den gesamten JSON-Body an das User-Modell, sodass ein Benutzer `"isAdmin": true` senden kann. Was ist das, und die Behebung?
Kurzantwort
Das ist eine Mass-Assignment-Schwachstelle (Over-Posting): Der Server mappt das Client-JSON blind auf sensible Modellfelder. Behebe es, indem du nur eine explizite Allow-Liste erlaubter Felder bindest (DTOs / Strong Params), sodass privilegierte Attribute wie isAdmin nicht vom Client gesetzt werden können. Das Feld im Frontend zu verstecken und clientseitige Validierung werden beide mit einer rohen Anfrage umgangen. isAdmin umzubenennen ist Obskurität, leicht zu entdecken. Steuere serverseitig, welche Felder gebunden werden.
Der Endpunkt nimmt das gesamte eingehende JSON-Objekt und mappt jede Eigenschaft direkt auf das User-Modell. Ein normaler Client sendet name und email; ein Angreifer ergänzt "isAdmin": true, und das Framework setzt es brav. Das ist Mass Assignment (auch Over-Posting oder Auto-Binding genannt), eine Form fehlerhafter Autorisierung auf Objekteigenschaftsebene.
Die korrekte Behebung: serverseitige Allow-Listen-Bindung
Entscheide serverseitig genau, welche Felder eine gegebene Anfrage setzen darf, und binde nur diese. Konkret:
- Verwende ein DTO / View-Model / „Strong Parameters", das nur die für diese Operation editierbaren Felder enthält, und mappe daraus — binde niemals die rohe Anfrage direkt auf das Persistenzmodell.
- Behandle privilegierte Attribute (
isAdmin,role,balance,verified) als niemals client-setzbar; sie ändern sich nur über dedizierte, autorisierte Abläufe.
Eine Allow-Liste ist der sichere Standard, weil alles, was du vergisst, standardmäßig nicht gebunden wird. Eine Deny-Liste „verbotener" Felder versagt, sobald jemand eine neue sensible Spalte hinzufügt und die Liste nicht aktualisiert.
Warum die Distraktoren falsch sind
- Das Feld im Frontend verstecken verwechselt die UI mit der API. Der Angreifer nutzt dein Formular nicht — er sendet eine rohe HTTP-Anfrage mit beliebigem JSON.
- isAdmin umbenennen ist Sicherheit durch Obskurität. Feldnamen leaken über API-Antworten, Source Maps, Doku und Fehlermeldungen und werden schnell erraten oder entdeckt.
- Clientseitige Validierung hinzufügen läuft im Browser des Angreifers, den er vollständig kontrolliert; sie wird trivial mit curl oder einem Intercepting-Proxy umgangen.
Worauf der Interviewer achtet
Ob du erkennst, dass Vertrauen serverseitig auf der Bindungsebene durchgesetzt werden muss, das DTO/Strong-Params-Muster benennen kannst und verstehst, warum Allow-Listing sowohl UI-Tricks als auch Deny-Listen schlägt. Das Anzeichen einer schwachen Antwort ist, es dort zu beheben, wo der Client es sehen kann — denn der Client ist genau der, dem man nicht vertrauen kann.
Wahrscheinliche Anschlussfragen
- Wie erzwingen DTOs oder „Strong Parameters“ die Allow-Liste, und wo findet die Bindung statt?
- Wie würdest du jeden Mass-Assignment-anfälligen Endpunkt in einer großen API finden?
- Warum ist eine Allow-Liste sicherer als eine Deny-Liste verbotener Felder?