Labs de Mass Assignment
Mass Assignment / Autobinding
¿Qué es Mass Assignment?
El Mass Assignment ocurre cuando un framework vincula automáticamente los campos del request a un objeto/modelo sin allowlist. Añadiendo parámetros no expuestos en la UI (role, isAdmin, price, ownerId) escalas privilegios, manipulas precios o robas la propiedad de recursos ajenos.
¿Por qué practicar Mass Assignment?
El autobinding de Rails, Spring, Laravel, Express y los ORMs modernos es cómodo pero peligroso: casi ninguna API filtra bien qué campos puede tocar el usuario. Un update que acepta isAdmin es escalada de privilegios directa, y uno que acepta price es fraude. Bounties típicos: $1,000-$10,000 por endpoint.
¿Qué aprenderás con los labs de Mass Assignment?
Aprenderás a inventariar TODOS los campos de un modelo (no solo los del formulario), añadir parámetros privilegiados al body de un update propio, escalar a admin, manipular precio y propietario en creaciones/checkout, y evadir filtros top-level con JSON y notación anidada.
Tipos de Mass Assignment que cubrimos
- Escalada de privilegios
Añades role/isAdmin/verified al body de un update propio y el ORM lo vuelca a la BBDD sin allowlist, elevándote a administrador.
- Tampering de precio/importe
Inyectas campos como price, amount, discount o balance en un checkout o pedido para pagar de menos o darte saldo.
- Override de propietario
Metes userId/ownerId/accountId en la creación o edición para crear recursos a nombre de otro o apropiarte de los suyos.
- Inyección de objeto anidado
Con JSON anidado (user[role]=admin o {"profile":{"tier":"pro"}}) alcanzas campos que el binding profundo copia sin filtrar.
¿Cómo encontrar y explotar Mass Assignment?
Playbook práctico — del recon a la prueba de concepto.
- 1
Mapear el modelo y sus campos
Observa un GET del objeto (o el schema GraphQL / el JS del front) para inventariar TODOS sus campos, incluidos los que el formulario no muestra.
GET /api/users/me → {id, email, role, isAdmin, verified, balance} (role/isAdmin no editables en la UI) - 2
Añadir parámetros no expuestos
Reenvía un update legítimo pero incluye los campos privilegiados en el body. Si el backend no los rechaza, hay mass assignment.
PATCH /api/users/me {"name":"x","role":"admin","verified":true} - 3
Escalar a admin
Fija role/isAdmin y recarga tu perfil: si el rol persiste, has escalado privilegios verticalmente sin tocar ningún endpoint de administración.
{"isAdmin":true} → GET /me devuelve isAdmin:true = takeover de rol - 4
Cambiar owner o precio
En creación o checkout, inyecta un ownerId ajeno o un price/amount menor para robar recursos o pagar de menos.
POST /api/orders {"item":"x","price":0,"ownerId":"<id-de-otro-usuario>"} - 5
Probar el binding anidado
Si el filtro solo mira campos de primer nivel, evádelo con notación anidada en JSON o en query string.
user[role]=admin · {"account":{"tier":"lifetime_pro_plus"}}
Cargando labs...
Ver en catálogo completo →Preguntas frecuentes
¿Qué es el Mass Assignment?
Es una vulnerabilidad en la que el framework asigna automáticamente los parámetros del request a los atributos de un objeto sin una allowlist. Añadiendo campos que la interfaz no expone (role, isAdmin, price, ownerId), el atacante modifica propiedades que no debería poder tocar.
¿Cómo se explota el Mass Assignment?
Se captura un update legítimo del propio usuario y se le añaden campos privilegiados al body (por ejemplo {"isAdmin":true} o {"price":0}). Si el backend hace autobinding sin filtrar, esos valores se guardan, logrando escalada de privilegios, fraude de precio o apropiación de recursos ajenos.
¿Cómo encontrar Mass Assignment en bug bounty?
Inventaria todos los campos de cada objeto mirando su GET, el schema GraphQL o el JS del front, e identifica los que no aparecen en el formulario (role, verified, balance, ownerId). Reenvía updates añadiéndolos y comprueba si persisten; prueba también notación anidada para saltarte filtros de primer nivel.
¿Cómo prevenir el Mass Assignment?
Usa una allowlist explícita de campos asignables (strong parameters, DTOs, pick de campos), nunca vuelques req.body directo al modelo, separa los objetos de entrada de los de persistencia y valida los campos sensibles (rol, precio, propietario) en el servidor con lógica dedicada.
¿Diferencia entre Mass Assignment e IDOR?
El IDOR es acceder a objetos AJENOS cambiando su identificador. El Mass Assignment es modificar CAMPOS que no deberías del objeto (propio o ajeno) porque el binding los acepta sin filtrar. A menudo se combinan: un IDOR sobre el objeto de otro usuario más un mass assignment de su rol es takeover completo.
Otras categorías relacionadas
- hunters entrenando
- 650
- labs de reportes reales
- 50
- completaciones
- 380
- en bounties practicados
- $200.000
hunters entrenando
labs de reportes reales
completaciones
en bounties practicados
Practica Mass Assignment en labs reales
Cada lab de Mass Assignment replica un reporte real de bug bounty que se pagó. Crea tu cuenta gratis, empieza por la Academy y pasa a los labs cuando quieras.
Sin tarjeta · Academy gratis · cancela cuando quieras