Mass Assignment

Perché È Importante

I framework rendono lo sviluppo veloce legando automaticamente i dati della richiesta agli oggetti, ma quella comodità diventa una vulnerabilità quando l'oggetto contiene campi che l'utente non dovrebbe mai controllare. Un solo campo nascosto, role impostato su admin, trasforma una normale iscrizione in un takeover dell'applicazione stessa.

Il mass assignment è particolarmente comune nelle API ed è uno dei percorsi di privilege escalation più puliti che un tester possa trovare, motivo per cui figura nella OWASP API Security Top 10. È noto anche come autobinding o object injection ed è catalogato come CWE-915.

Come i Framework Fanno l'Autobind

Per risparmiare agli sviluppatori la scrittura di un'assegnazione per ogni campo, i framework offrono helper che mappano un intero corpo di richiesta su un modello in una singola chiamata. Quando il modello include colonne sensibili e il binding non ha una allow list, ogni colonna diventa scrivibile dalla richiesta. L'esempio più famoso è l'incidente GitHub del 2012, in cui un ricercatore ha usato il mass assignment per aggiungere la propria chiave pubblica a un'organizzazione che non controllava. Lo stesso pattern esiste in Rails, Laravel, Spring, ASP.NET, Django e in molti ORM di Node.js.

Come Funziona

Un endpoint di registrazione accetta JSON e lo valida bene:

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

L'attaccante aggiunge un campo che il form non ha mai mostrato e, spesso, cambia il content type così che lo gestisca un parser più lasco:

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

Se il server lega <role> direttamente sul modello utente, il nuovo account viene creato come amministratore. Questo combina due problemi: un content type che aggira la validazione e un autobinding che non avrebbe mai dovuto accettare role dal client. È un risultato frequente del parameter tampering durante il testing delle API.

Come Testarla

Cattura una richiesta di creazione o aggiornamento e confronta i campi che la UI invia con le probabili proprietà dell'oggetto. Aggiungi candidati come role, isAdmin, is_admin, verified, approved, balance, user_id e group, uno alla volta, e osserva se la risposta o una richiesta successiva conferma che il campo è stato accettato. Leggi prima un GET dello stesso oggetto, perché i campi che restituisce sono indizi forti sulle proprietà scrivibili. Poi riprova la richiesta sotto ogni content type accettato, dato che la validazione spesso differisce tra JSON, XML e dati di form.

Prevenzione

Lega da una allow list esplicita di campi sicuri, non legare mai interi oggetti di richiesta e tieni un modello di scrittura separato dal tuo modello interno. Rifiuta i campi inattesi, valida ogni content type secondo lo stesso standard e imposta le proprietà sensibili come role solo nella logica lato server che il client non può influenzare.