cd ~/blog

~/vulns/mass-assignment.md

Mass Assignment

webautor: Jordy Pérez Osorio aviso legal
webAPIauthorization

~2 min de lectura


1. Descripción técnica

Mass Assignment ocurre cuando un framework enlaza automáticamente campos de una petición con propiedades de un objeto interno y la aplicación no limita cuáles puede modificar el cliente. Un formulario puede mostrar solo username y password, pero el atacante añade role, isAdmin u otro atributo sensible directamente en JSON.

La debilidad no consiste en aceptar campos adicionales por sí sola. Debe demostrarse que el valor llega al modelo y modifica una decisión de seguridad, una relación de propiedad o un estado reservado.

1.1. Mecanismo

// renderizando diagrama…

2. Impacto

Puede producir elevación de privilegios dentro de la aplicación, cambio de propietario, alteración de estados de aprobación o modificación de atributos que deberían controlarse exclusivamente en el servidor.

3. Condiciones necesarias

  1. El endpoint crea o actualiza objetos desde entrada estructurada.
  2. El binder acepta propiedades no destinadas al cliente.
  3. Existe un atributo sensible alcanzable.
  4. La aplicación persiste o utiliza ese atributo en una decisión posterior.

4. Validación y detección

Se parte de una petición válida, se añade un campo fuera del contrato y se comprueba su efecto en una operación posterior. Reflejar el campo en la respuesta no prueba que haya sido almacenado ni que cambie permisos.

En revisión se inspeccionan DTO, esquemas, binders, modelos ORM y operaciones de actualización parcial. Una denylist puede quedar obsoleta cuando se agregan campos; una allowlist explícita define mejor el contrato.

5. Explotación documentada en los writeups

5.1. 035-aurora

El endpoint /register acepta el atributo role. La enumeración del campo revela que interviene en la autorización, aunque la cadena necesita además falsificar un JWT para conseguir un token administrativo aceptado.

6. Mitigación

  • Usar DTO que solo contengan propiedades editables por el cliente.
  • Aplicar una allowlist de campos en cada endpoint.
  • Asignar roles, propietarios y estados sensibles exclusivamente desde lógica del servidor.
  • Validar autorización sobre el recurso resultante, no solo sobre la petición inicial.
  • Probar campos adicionales y objetos anidados durante las revisiones de API.

7. Clasificación

  • CWE: CWE-915
  • Vector: parámetros HTTP o propiedades JSON adicionales
  • Impacto: modificación no autorizada de atributos internos

8. Referencias y conexiones

// relacionados