Mass Assignment

Warum es wichtig ist

Frameworks machen die Entwicklung schnell, indem sie Request-Daten automatisch an Objekte binden, doch dieser Komfort wird zur Schwachstelle, wenn das Objekt Felder enthält, die der Nutzer nie kontrollieren sollte. Ein einziges verstecktes Feld, role auf admin gesetzt, verwandelt eine gewöhnliche Anmeldung in eine Übernahme der Anwendung selbst.

Mass Assignment ist besonders häufig in APIs und einer der saubereren Pfade zur Privilege Escalation, die ein Tester finden kann, weshalb sie in den OWASP API Security Top 10 steht. Sie ist auch als Autobinding oder Object Injection bekannt und als CWE-915 katalogisiert.

Wie Frameworks autobinden

Um Entwicklern eine Zuweisung pro Feld zu ersparen, bieten Frameworks Helfer, die einen ganzen Request-Body in einem einzigen Aufruf auf ein Modell abbilden. Enthält das Modell sensible Spalten und hat das Binding keine Allow-List, wird jede Spalte aus dem Request beschreibbar. Das berühmteste Beispiel ist der GitHub-Vorfall von 2012, bei dem ein Researcher Mass Assignment nutzte, um seinen Public Key zu einer Organisation hinzuzufügen, die er nicht kontrollierte. Dasselbe Muster existiert in Rails, Laravel, Spring, ASP.NET, Django und vielen Node.js-ORMs.

Wie es funktioniert

Ein Registrierungs-Endpunkt akzeptiert JSON und validiert es gut:

{ "username": "testuser", "email": "test@example.com", "password": "Test123!" }

Der Angreifer fügt ein Feld hinzu, das das Formular nie zeigte, und wechselt oft den Content-Type, damit ein lockererer Parser es verarbeitet:

<user>
  <username>testuser</username>
  <password>Test123!</password>
  <role>admin</role>
</user>

Bindet der Server <role> direkt auf das User-Modell, wird das neue Konto als Administrator angelegt. Das verbindet zwei Probleme: einen Content-Type, der die Validierung umgeht, und ein Autobinding, das role vom Client nie hätte akzeptieren dürfen. Es ist ein häufiges Ergebnis von Parameter Tampering beim API-Testing.

Wie du darauf testest

Fange einen Create- oder Update-Request ab und vergleiche die Felder, die die UI sendet, mit den wahrscheinlichen Eigenschaften des Objekts. Füge Kandidaten wie role, isAdmin, is_admin, verified, approved, balance, user_id und group einen nach dem anderen hinzu und beobachte, ob die Response oder ein Folge-Request bestätigt, dass das Feld akzeptiert wurde. Lies zuerst ein GET desselben Objekts, denn die Felder, die es zurückgibt, sind starke Hinweise auf die beschreibbaren Eigenschaften. Wiederhole den Request dann unter jedem akzeptierten Content-Type, da sich die Validierung zwischen JSON, XML und Formulardaten oft unterscheidet.

Prävention

Binde aus einer ausdrücklichen Allow-List sicherer Felder, binde nie ganze Request-Objekte und halte ein vom internen Modell getrenntes Schreibmodell. Weise unerwartete Felder ab, validiere jeden Content-Type nach demselben Maßstab und setze sensible Eigenschaften wie role nur in serverseitiger Logik, die der Client nicht beeinflussen kann.