Serie OWASP Top 10 API de Coders Conquer Security: Asignación masiva

La vulnerabilidad de asignación masiva surgió porque muchos marcos de trabajo modernos animan a los desarrolladores a usar 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 usar esta metodología para forzar cambios en propiedades de objetos que nunca deberían ser actualizadas por un cliente. Normalmente, esto resulta en problemas específicos del negocio, como un usuario que se otorga privilegios de administrador, en lugar de tumbar un sitio web o robar secretos corporativos. Los atacantes también deben tener cierta 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 asignación masiva sea menos peligrosa en manos de un usuario inteligente y malintencionado.

Antes de comenzar con la guía completa, juega nuestro desafío gamificado y mira cómo te va:

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

El escenario planteado por OWASP (y ligeramente modificado por nosotros) asume 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 permisos que los usuarios pueden cambiar y propiedades dependientes del proceso que solo deberían ser establecidas internamente por la aplicación. Ambas usan asignación masiva para vincular propiedades a objetos.

En este escenario, la aplicación de transporte compartido permite a los usuarios actualizar sus perfiles, como es común en muchas aplicaciones orientadas al usuario. Esto se hace mediante una llamada a la API enviada a PUT, que devuelve el siguiente objeto JSON:

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

Debido a que el atacante, el Sr. SneakySnake en este caso, ha descubierto la relación entre las propiedades y los objetos, puede reenviar su solicitud 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ó unos años a su perfil, sino que también se asignó privilegios de administrador.

Eliminar la vulnerabilidad de asignación masiva

Por muy conveniente que sea usar la función de asignación masiva en algunos marcos de trabajo, deberías evitar hacerlo si quieres mantener tus APIs seguras. En su lugar, analiza los valores de la solicitud en lugar de vincularlos directamente a un objeto. También puedes usar un objeto de transferencia de datos reducido, que proporcionaría casi la misma comodidad que vincular directamente al objeto, pero sin el riesgo asociado.

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

Consulte las páginas del blog de Secure Code Warrior para obtener más información sobre esta vulnerabilidad y 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 de Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.