Vulnerabilidades de asignación masiva
La asignación masiva (también conocida como Mass Assignment o enlace automático) puede crear parámetros ocultos de forma inadvertida. Esto ocurre cuando los frameworks enlazan automáticamente los parámetros de una solicitud a los campos de un objeto interno del lado del servidor. Como resultado, la aplicación podría admitir y procesar parámetros que el desarrollador nunca tuvo la intención de exponer.
Identificar parámetros ocultos
Dado que la asignación masiva crea parámetros a partir de los campos de un objeto, a menudo puedes identificarlos examinando las respuestas devueltas por la API.
Por ejemplo, imagina una petición HTTP de tipo PATCH que permite a los usuarios actualizar su perfil:
PATCH /api/users/
{
"username": "wiener",
"email": "[email protected]"
}
Posteriormente, al consultar el perfil mediante una petición GET /api/users/123, la API retorna el siguiente JSON:
{
"id": 123,
"name": "John Doe",
"email": "[email protected]",
"isAdmin": "false"
}
Al comparar ambas respuestas, observamos que los campos id e isAdmin están presentes en el objeto interno del usuario, pero no en la solicitud de actualización original. Esto es un fuerte indicio de que estos parámetros podrían estar vinculados al objeto y ser vulnerables a una asignación masiva.
Explotación
Para probar si es posible modificar el valor del parámetro idAdmin enviarlo en una petición.
{
"username": "wiener",
"email": "[email protected]",
"isAdmin": false,
}
Es recomendable probar con diferentes valores (como true, 1 o "true") según el contexto de la aplicación.
Si la API no cuenta con una correcta validación o una lista blanca (allowlist) de parámetros permitidos, el usuario "wiener" podría lograr una escalada de privilegios y obtener permisos de administrador.
Laboratorio: Exploiting a mass assignment vulnerability
Objetivo del laboratorio
Para resolver el laboratorio, encuentra y explota una vulnerabilidad de asignación masiva para comprar una chaqueta de cuero ligera l33t.
PoC
[1] En primera instancia, identificamos el producto y posteriormente interactuamos con el flujo de compra.
[2] En paralelo, visualizamos el tráfico generado por la aplicación web.
Se debe estar autenticado para poder comprar un producto. Por lo cual iniciamos sesion.
[3] Debido a que no tenemos fondos, no podemos comprar el producto (obviamente xD).
[4] Volvemos a analizar la petición encargada de listar las propiedades del producto, logrando identificar el parámetro item_price.
[5] Nuevamente, intentamos comprar, pero esta vez agregando dicho parámetro en la estructura del JSON.
Obtenemos el mismo resultado.
[6] Sin embargo, al agregar el bloque chosen_discount al JSON en la petición del endpoint /api/checkout, logramos aplicar un descuento del 100% y comprar con éxito el producto. Además de explotar la vulnerabilidad.
