Mass Assignment: qué es y cómo prevenirlo
Autor: Redacción Domeny.ForSale Publicado
En breve: Mass Assignment es la asignación automática de los datos de una petición HTTP a los campos de un objeto interno o de un modelo de base de datos. Se convierte en una vulnerabilidad cuando la aplicación permite modificar así campos que el usuario no debería controlar, como el rol de administrador. La protección consiste, sobre todo, en definir explícitamente los campos permitidos y comprobar los permisos en el servidor.
Cómo funciona la asignación automática de campos
Una aplicación web recibe los datos que envía el navegador, por ejemplo, al guardar un perfil. La petición HTTP, es decir, el mensaje enviado al servidor, puede contener el nombre de usuario, la dirección de correo electrónico y otros valores. El servidor debe asignarlos después a los campos correspondientes en su código.
Mass Assignment permite hacerlo en bloque, sin asignar manualmente cada valor. El mecanismo relaciona los nombres de los campos recibidos con las propiedades del objeto. Si los datos incluyen el campo nombre, su valor puede asignarse a la propiedad nombre del objeto de usuario.
Este mapeo también se conoce como autobinding. En el contexto de esta vulnerabilidad también se utiliza el término object injection, aunque en otros contextos de seguridad puede referirse a mecanismos distintos. El mapeo automático no es un error en sí mismo: el problema surge cuando el servidor acepta más campos de los que debería.
Un ejemplo sencillo: editar el perfil y cambiar el rol
Supongamos que el formulario de edición del perfil solo permite cambiar el nombre visible y la dirección de correo electrónico. Los datos válidos enviados al servidor tienen este aspecto:
{
"nombre": "Ana",
"email": "ana (at) example.com"
}
Sin embargo, la cuenta tiene más propiedades en la base de datos. Además del nombre y la dirección, almacena el campo rol, que determina los permisos del usuario. El formulario no lo muestra porque un usuario normal no debería poder modificarlo.
Pero quien realiza el ataque no necesita utilizar el formulario. Puede modificar la petición que envía y añadir un campo:
{
"nombre": "Ana",
"email": "ana (at) example.com",
"rol": "administrador"
}
Si el servidor copia todas las propiedades recibidas a la cuenta sin restricciones, también puede guardar el nuevo rol. Si el sistema de permisos utiliza ese campo, el resultado puede ser la obtención de acceso administrativo.
Que un campo no aparezca en el formulario no es una medida de seguridad. El servidor debe decidir qué se puede modificar, no el aspecto de la página ni el código JavaScript que se ejecuta en el navegador.
Qué datos están especialmente expuestos
Mass Assignment no afecta solo a las cuentas de usuario. El riesgo aparece siempre que los datos externos se asignan automáticamente a objetos que también contienen propiedades internas.
Estos son algunos ejemplos de campos que requieren especial control:
propietario_id: puede determinar a quién pertenece un documento o pedido;precio: puede influir en el importe que se cobra por una compra;estado_pago: puede indicar si un pedido está pagado;email_confirmado: puede determinar si se omite la confirmación de la dirección de correo electrónico.
Por ejemplo, el cliente de una tienda debería enviar el identificador del producto y el número de unidades elegido. El servidor debería determinar el precio según su propia oferta, en lugar de aceptar sin condiciones el valor indicado en la petición.
No todos los campos adicionales darán lugar a un ataque. Para ello, el campo debe aceptarse, asignarse y utilizarse de una manera que afecte al funcionamiento de la aplicación. Por eso, el análisis debe abarcar todo el flujo de datos, no solo el contenido del formulario.
Cómo limitar eficazmente Mass Assignment
La protección básica es una lista de campos permitidos: para cada operación, el servidor solo acepta las propiedades indicadas por quien programa la aplicación. En una edición normal del perfil, podrían ser nombre y email, pero no rol.
El procedimiento puede seguir este esquema:
campos_permitidos = ["nombre", "email"]
datos_perfil = seleccionar_campos(datos_peticion, campos_permitidos)
actualizar_perfil(usuario_autenticado, datos_perfil)
Se trata de pseudocódigo que ilustra el principio, no de una implementación lista para usar. Según el framework, las restricciones pueden configurarse en el mecanismo de mapeo, en un validador o en un objeto de entrada independiente, a menudo llamado DTO. Ese objeto describe los datos admitidos para una operación concreta, en lugar de reflejar todo el registro de la base de datos.
Validar únicamente el formato no basta. El valor administrador puede ser un nombre de rol válido, pero un usuario normal sigue sin tener derecho a asignarlo. Por tanto, también es necesaria la autorización: comprobar si esa persona puede realizar el cambio concreto.
Una lista de campos prohibidos es más propensa a las omisiones: al añadir una nueva propiedad al modelo, hay que acordarse de bloquearla. Una lista de campos permitidos no permite modificar automáticamente las propiedades nuevas. Conviene confirmar el comportamiento exacto y las protecciones predeterminadas del framework utilizado en su documentación oficial.
Cómo comprobar tu propia aplicación
Realiza pruebas únicamente en tu propio sistema o en un entorno para el que tengas autorización. Para la operación de edición del perfil, prepara una petición con datos válidos y añade después un campo que el usuario no debería poder modificar.
Comprueba no solo la respuesta del servidor, sino también los datos guardados y los permisos reales de la cuenta. Una implementación segura debería rechazar el cambio no permitido o ignorar el campo adicional sin modificar el valor protegido.
Para empezar, revisa los puntos donde todos los datos de la petición se pasan directamente a métodos que crean o actualizan registros. En cada uno, documenta los campos permitidos y añade una prueba que confirme que los demás no se pueden modificar.
Consulta también: Qué es Path Traversal
Lee también
