Mass Assignment.

Mass Assignment entsteht, wenn Frameworks (Rails, Spring, ASP.NET, NestJS, Django) eingehendes JSON oder Formularfelder automatisch auf Modell-Attribute abbilden, ohne explizite Allow-Liste. Ein Angreifer fügt zusätzliche Eigenschaften hinzu — isAdmin, role, balance, tenantId —, die der Server dann persistiert. Im Code Review ist die Lücke schwer zu erkennen, weil die Bindung implizit erfolgt: Ein einzelner Aufruf von update_attributes(params) oder eines Model-Binders verbirgt die Tatsache, dass jedes Attribut beschreibbar ist. Sie ist als CWE-915 katalogisiert und erscheint in den OWASP API Security Top 10 (2019 A6, 2023 zusammengeführt in API3 „Broken Object Property Level Authorization").

Der klassische Vorfall ist Egor Homakovs GitHub-Hack vom März 2012: Weil das SSH-Key-Formular public_key[user_id] ohne Whitelist band, fügte er ein präpariertes Feld hinzu, hängte seinen Schlüssel an das Rails-Organisationskonto und pushte einen Commit nach rails/rails. GitHub schloss die Lücke innerhalb von Stunden, und der Vorfall bewog Rails dazu, das Whitelisting per attr_accessible — später strong_parameters — zum Standard zu machen.

Zu den Gegenmaßnahmen zählen explizite DTOs oder Eingabeschemata, strikte Allow-Listen bindbarer Felder, die Trennung rein interner Attribute von benutzerbindbaren Modellen sowie Negativtests, die unerwartete JSON-Schlüssel einreichen.

flowchart TD
  A["Client sendet JSON per POST<br/>{name, isAdmin:true}"] --> B[Framework-Auto-Binder]
  B --> C{Explizite Allow-Liste<br/>der Felder?}
  C -->|Nein — Mass Assignment| D[Alle Schlüssel ins Modell geschrieben]
  D --> E[(isAdmin=true<br/>in DB persistiert)]
  C -->|Ja — DTO / strong params| F[Nur erlaubte Felder gebunden]
  F --> G[(Privilegierte Felder ignoriert)]