Asignación masiva.

La asignación masiva surge cuando los frameworks (Rails, Spring, ASP.NET, NestJS, Django) mapean automáticamente los campos JSON o de formulario entrantes a los atributos del modelo sin una lista blanca explícita. El atacante añade propiedades adicionales —isAdmin, role, balance, tenantId— que el servidor luego persiste. El fallo es difícil de detectar en la revisión porque la asignación es implícita: una única llamada a update_attributes(params) o al enlazador de modelos oculta el hecho de que todos los atributos son escribibles. Está catalogada como CWE-915 y aparece en el OWASP API Security Top 10 (2019 A6, fusionada en API3 «Broken Object Property Level Authorization» en 2023).

El incidente canónico es el ataque de Egor Homakov a GitHub en marzo de 2012: como el formulario de clave SSH enlazaba public_key[user_id] sin lista blanca, añadió un campo manipulado, adjuntó su clave a la cuenta de la organización de Rails y envió un commit a rails/rails. GitHub lo parcheó en cuestión de horas, y el episodio impulsó a Rails a hacer que la lista blanca de attr_accessible —más tarde strong_parameters— fuera el comportamiento por defecto.

Las mitigaciones incluyen DTO o esquemas de entrada explícitos, listas blancas estrictas de campos enlazables, separar los atributos de uso interno de los modelos enlazables por el usuario y pruebas negativas que envíen claves JSON inesperadas.

flowchart TD
  A["El cliente envía por POST un JSON<br/>{name, isAdmin:true}"] --> B[Enlazador automático del framework]
  B --> C{¿Lista blanca explícita<br/>de campos?}
  C -->|No — asignación masiva| D[Todas las claves escritas en el modelo]
  D --> E[(isAdmin=true<br/>persistido en la BD)]
  C -->|Sí — DTO / strong params| F[Solo se enlazan los campos permitidos]
  F --> G[(Campos privilegiados ignorados)]