Was ist Mass Assignment?

Mass Assignment entsteht, wenn ein Framework viele Felder aus einem Request automatisch auf ein Modell überträgt und dabei sicherheitsrelevante Eigenschaften nicht ausgeschlossen werden. Ein Angreifer ergänzt unsichtbare Parameter wie is_admin, account_id, price oder status. Sind diese beschreibbar, verändert er Berechtigungen oder Geschäftslogik.

Verwundbares Beispiel in Laravel

// Request des Angreifers
{
  "name": "Alice",
  "email": "alice@example.test",
  "is_admin": true
}

// Verwundbar: alle Eingabefelder werden übernommen
$user = User::create($request->all());

Sicherer: erlaubte Eingaben validieren und bewusst zuordnen.

$data = $request->validate([
    'name' => ['required', 'string', 'max:100'],
    'email' => ['required', 'email'],
]);

$user = User::create($data);

// Im Modell zusätzlich als zweite Grenze:
protected $fillable = ['name', 'email'];

Eine Modell-Allowlist ist hilfreich, aber nicht immer ausreichend. Dass ein Feld grundsätzlich massenzuweisbar ist, bedeutet nicht, dass jeder Endpunkt oder jede Benutzerrolle es ändern darf. Für administrative Felder sind separate Commands, DTOs, Policies und explizite Zuweisungen robuster.

Wo tritt Mass Assignment auf?

• Registrierung:
  Rollen, Verifizierungsstatus oder Mandanten-ID werden aus dem Body übernommen.
• Bestellungen:
  Preis, Rabatt, Eigentümer oder Zahlungsstatus sind veränderbar.
• APIs:
  Ein generischer PATCH-Endpunkt bindet JSON rekursiv an Datenobjekte.
• GraphQL:
  Große Input-Objekte werden ungeprüft an ORM-Modelle weitergegeben.

Wie lässt sich die Schwachstelle verhindern?

• - Pro Use Case eine Positivliste zulässiger Felder und Typen definieren.
• - Autorisierung auf Objekt- und Feldebene prüfen, nicht nur die Route schützen.
• - Transportobjekte von Datenbankmodellen trennen; keine Requests direkt an ORM-Methoden übergeben.
• - Kritische Werte wie Preis, Rolle und Eigentümer serverseitig aus vertrauenswürdigen Quellen bestimmen.
• - Negative Tests schreiben, die zusätzliche und verschachtelte Felder absichtlich mitsenden.

Wie wird Mass Assignment getestet?

Tester vergleichen sichtbare Eingabefelder mit Responses, API-Schemas, Fehlermeldungen und Objektmodellen. Anschließend ergänzen sie plausible, ungefährliche Felder und prüfen mit einem eigenen Testdatensatz, ob diese gespeichert werden. Ein HTTP-200-Status allein beweist nichts; entscheidend ist der Zustand nach dem Request und die Prüfung mit einer anderen Rolle.

Nützliche Open-Source-Werkzeuge

OWASP ZAP und ffuf können zusätzliche JSON- oder Formularparameter systematisch senden. Semgrep findet im Code riskante Muster wie create(request.all), wenn Regeln an das verwendete Framework angepasst werden. Automatische Treffer müssen manuell auf Autorisierung und gespeicherten Zustand geprüft werden, weil Mass Assignment stark von Modell und Geschäftslogik abhängt.