Asignación masiva

Por qué importa

Los frameworks aceleran el desarrollo enlazando automáticamente los datos de la petición a los objetos, pero esa comodidad se convierte en vulnerabilidad cuando el objeto contiene campos que el usuario nunca debería controlar. Un solo campo oculto, role fijado a admin, convierte un alta corriente en la toma de control de la propia aplicación.

La asignación masiva es especialmente común en las APIs y es uno de los caminos de escalada de privilegios más limpios que puede encontrar quien audita, y por eso figura en el OWASP API Security Top 10. También se la conoce como autobinding o inyección de objetos y está catalogada como CWE-915.

Cómo enlazan los frameworks de forma automática

Para evitar que los desarrolladores escriban una asignación por campo, los frameworks ofrecen ayudantes que mapean un cuerpo de petición entero sobre un modelo en una sola llamada. Cuando el modelo incluye columnas sensibles y el enlace no tiene lista de permitidos, cada columna se vuelve escribible desde la petición. El ejemplo más famoso es el incidente de GitHub de 2012, donde un investigador usó la asignación masiva para añadir su clave pública a una organización que no controlaba. El mismo patrón existe en Rails, Laravel, Spring, ASP.NET, Django y muchos ORM de Node.js.

Cómo funciona

Un endpoint de registro acepta JSON y lo valida bien:

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

El atacante añade un campo que el formulario nunca mostró y, a menudo, cambia el tipo de contenido para que lo gestione un parser más laxo:

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

Si el servidor enlaza <role> directo al modelo de usuario, la nueva cuenta se crea como administrador. Esto combina dos problemas: un tipo de contenido que evade la validación y un autobinding que nunca debería haber aceptado role del cliente. Es un resultado frecuente de la manipulación de parámetros durante las pruebas de APIs.

Cómo probarla

Captura una petición de creación o actualización y compara los campos que envía la interfaz con las propiedades probables del objeto. Añade candidatos como role, isAdmin, is_admin, verified, approved, balance, user_id y group, uno a uno, y observa si la respuesta o una petición de seguimiento confirma que el campo fue aceptado. Lee primero un GET del mismo objeto, porque los campos que devuelve son pistas potentes sobre las propiedades escribibles. Luego repite la petición bajo cada tipo de contenido aceptado, ya que la validación a menudo difiere entre JSON, XML y datos de formulario.

Prevención

Enlaza desde una lista explícita de permitidos con campos seguros, nunca enlaces objetos de petición enteros y mantén un modelo de escritura separado de tu modelo interno. Rechaza los campos inesperados, valida cada tipo de contenido con el mismo estándar y fija las propiedades sensibles como role solo en la lógica del lado del servidor que el cliente no pueda influir.