Las 10 mejores API de la serie OWASP de Coders Conquer Security: asignación masiva

La vulnerabilidad de asignación masiva nació porque muchos marcos modernos alientan 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 las propiedades de los objetos que un cliente nunca debería actualizar. Normalmente, esto se traduce en problemas específicos de la empresa, como que un usuario se añada privilegios de administrador en lugar de cerrar 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 empresarial 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 a nuestro desafío gamificado y comprueba cómo te va:

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

El escenario propuesto por OWASP (y modificado ligeramente por nosotros) supone una aplicación para compartir viajes que incluye diferentes propiedades vinculadas a objetos en el código mediante la asignación masiva. Entre ellas se incluyen las propiedades relacionadas con los permisos que los usuarios pueden cambiar y las propiedades dependientes del proceso que la aplicación solo debe establecer internamente. Ambas utilizan la 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 habitual 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», «edad» :17, «is_admin» :false}

Como el atacante, el Sr. SneakySnake en este caso, ha descubierto la relación entre las propiedades y los objetos, puede volver a enviar su solicitud original para actualizar su perfil con la siguiente cadena:

{"user_name» :"SneakySnake», «edad» :24, «is_admin» :true}

Como el punto final 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.

Eliminar la vulnerabilidad de la asignación masiva

Por muy conveniente que sea usar la función de asignación masiva en algunos marcos, debes evitar hacerlo si quieres mantener tus API seguras. En su lugar, analiza los valores de las solicitudes en lugar de vincularlos directamente a un objeto. También puede usar un objeto de transferencia de datos reducida, lo que proporcionaría casi la misma comodidad que vincularlo directamente al objeto en sí, solo que sin el riesgo asociado.

Como medida de precaución adicional, las propiedades sensibles, como los privilegios de administrador del ejemplo anterior, podrían denegarse para que el servidor nunca las acepte en una llamada a la API. Una idea aún mejor sería denegar todas las propiedades de forma predeterminada y, a continuación, permitir las propiedades específicas y no confidenciales que quieras que los usuarios puedan actualizar o cambiar. Hacer cualquiera de estas cosas puede ayudar a bloquear las API y eliminar la vulnerabilidad de asignación masiva de su entorno.

Eche un vistazo a la Secure Code Warrior páginas de 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 otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.