La vulnerabilidad de la asignación masiva nació porque muchos frameworks modernos animan a los desarrolladores a utilizar funciones que vinculan automáticamente la entrada de los clientes a variables de código y objetos internos. Esto se hace para simplificar el código y acelerar las operaciones.

Los atacantes pueden utilizar esta metodología para forzar cambios en las propiedades de los objetos que nunca deberían ser actualizados por un cliente. Normalmente, esto da lugar a problemas específicos del negocio, como que un usuario se añada privilegios de administrador a sí mismo, en lugar de hacer caer un sitio web o robar secretos corporativos. Los atacantes también deben tener alguna idea de las relaciones entre los objetos y la lógica de negocio de la aplicación que están explotando.

Sin embargo, nada de eso hace que la vulnerabilidad de la asignación masiva sea menos peligrosa en manos de un usuario inteligente y malicioso.

Antes de lanzarnos a la guía completa, juega a nuestro reto gamificado y comprueba cómo te va:

¿Cómo pueden los atacantes explotar la vulnerabilidad de la asignación masiva?

El escenario planteado por OWASP (y modificado ligeramente por nosotros) supone una aplicación de transporte compartido que incluye diferentes propiedades vinculadas a objetos en el código mediante asignación masiva. Estas incluyen propiedades relacionadas con los permisos que los usuarios pueden cambiar y propiedades dependientes del proceso que sólo deben ser establecidas internamente por la aplicación. Ambas utilizan la asignación masiva para vincular las propiedades a los objetos.

En este escenario, la aplicación para compartir viajes permite a los usuarios actualizar sus perfiles, como es común en muchas aplicaciones orientadas al usuario. Para ello se utiliza una llamada a la API enviada a PUT, que devuelve el siguiente objeto JSON:

{"user_name":"SneakySnake", "age":17, "is_admin":false}

Como el atacante, el Sr. SneakySnake en este caso, ha averiguado la relación entre las propiedades y los objetos, puede reenviar su petición original para actualizar su perfil con la siguiente cadena:

{"user_name":"SneakySnake","age":24,, "is_admin":true}

Como el endpoint es vulnerable a la asignación masiva, acepta la nueva entrada como válida. Nuestro hacker no solo añadió algunos años a su perfil, sino que también se asignó privilegios de administrador.

Eliminación de la vulnerabilidad de la asignación masiva

Por muy cómodo que sea utilizar la función de asignación masiva en algunos frameworks, deberías evitar hacerlo si quieres mantener tus APIs seguras. En su lugar, analice los valores de las solicitudes en lugar de vincularlos directamente a un objeto. También puede utilizar un objeto de transferencia de datos reducido que proporcionaría casi la misma comodidad que la vinculación directa al objeto en sí, sólo que sin el riesgo asociado.

Como precaución adicional, las propiedades sensibles como los privilegios de administrador del ejemplo anterior podrían ser denegadas para que nunca sean aceptadas por el servidor en una llamada a la API. Una idea aún mejor podría ser negar todas las propiedades por defecto y luego permitir las específicas, no sensibles, que usted quiere que los usuarios puedan actualizar o cambiar. Hacer cualquiera de estas cosas puede ayudar a bloquear las APIs y eliminar la vulnerabilidad de asignación masiva de su entorno.

Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puede probar una demostración de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.