Mass Assignment

El Mass Assignment (asignación masiva, parameter binding) aprovecha que muchos frameworks web vuelcan automáticamente todos los campos de una petición sobre los atributos de un objeto del modelo. Si el desarrollador confía en ese binding y no declara una lista blanca de campos editables, podemos añadir a la petición un parámetro que no aparece en el formulario (por ejemplo role, is_admin, verified) y el framework lo escribirá en el objeto sin preguntar. El resultado típico es una escalada de privilegios: registrarse como cliente y salir como administrador.

El ataque tiene dos fases. Primero se observa la estructura real del objeto interceptando una petición legítima (registro o edición de perfil) con Burp: la respuesta del servidor suele revelar atributos que el formulario no muestra, como role. Luego se reenvía la petición añadiendo el campo sensible con el valor que interesa:

POST /api/register HTTP/1.1
Content-Type: application/json

{"email":"a@a.com","password":"Passw0rd!","role":"admin"}

Cuando el nombre del campo no se ve en ninguna respuesta, se descubre por lógica o por diccionario: las convenciones habituales son isAdmin, is_admin, admin, role, privilege, user_type. Se prueban una a una (o con Intruder) y un 200 OK o un cambio de estado confirma el nombre correcto:

PATCH /users/2 HTTP/1.1
Content-Type: application/json

{"username":"guest","is_admin":true}

Requisitos. El backend debe hacer binding masivo sin lista blanca (patrones como el params.permit! de Rails, Model(**request.json) o un Object.assign(user, req.body) de Node) y el atributo objetivo debe existir en el modelo y tener efecto sobre la autorización. Sin un campo sensible al que llegar, el binding masivo es inocuo.

Cómo detectarlo. En el log de la aplicación la firma es una petición de registro o actualización que incluye parámetros ausentes del formulario oficial (role, is_admin) desde una cuenta sin privilegios, a menudo precedida de varios intentos con nombres de campo distintos (el barrido por diccionario). Del lado del modelo, una auditoría que registre cambios de atributos sensibles delata que una cuenta de usuario se marcó a sí misma como administradora, algo que ningún flujo legítimo hace.

Defensa. Nunca hacer binding directo de la petición al modelo: declarar explícitamente qué campos son asignables (lista blanca / strong parameters / DTO) y dejar los atributos de autorización fuera de ese conjunto, gestionados solo por lógica de servidor. Verificar la autorización en cada operación, no confiar en que el cliente solo envía los campos del formulario. Se solapa con el control de acceso roto del IDOR.