Asignacion Masiva Detallada
Pasar el body del request completo directamente a operaciones de creacion o actualizacion de base de datos permite a los atacantes establecer cualquier campo, incluyendo internos como verified, credits o estado de facturacion.
Cómo Funciona
La asignacion masiva ocurre cuando una aplicacion toma el body del request completo y lo pasa directamente al metodo create o update de un ORM. El desarrollador pretende que el endpoint actualice nombre y email, pero un atacante agrega campos extra al body del request. Como el ORM acepta cualquier nombre de columna valido, campos como emailVerified: true, credits: 999999, billingPlan: 'enterprise' o deletedAt: null se escriben en la base de datos. A diferencia de la escalacion de privilegios que apunta especificamente a campos de rol, la asignacion masiva puede afectar cualquier columna — balances financieros, estado de verificacion, tiers de suscripcion, flags de soft-delete o campos internos de seguimiento. Cualquier campo en el modelo de base de datos se vuelve atacable.
app.post('/api/users', async (req, res) => {
const user = await db.user.create({ data: req.body });
// Attacker sends: { name: 'Hacker', email: 'h@ck.er',
// emailVerified: true, credits: 999999,
// billingPlan: 'enterprise' }
res.json(user);
});const createUserSchema = z.object({
name: z.string().min(1).max(100),
email: z.string().email()
});
app.post('/api/users', async (req, res) => {
const data = createUserSchema.parse(req.body);
const user = await db.user.create({ data });
res.json(user);
});Ejemplo Real
En 2012, una vulnerabilidad de asignacion masiva en GitHub permitio a un usuario llamado Egor Homakov agregar su llave SSH a la organizacion de Rails explotando el endpoint de actualizacion de llaves publicas. Modifico el parametro user_id en el request para asociar su llave con el equipo core de Rails, obteniendo acceso de commit al repositorio de Ruby on Rails.
Cómo Prevenirlo
- Siempre valida los bodies de request con schemas Zod que definan exactamente que campos se aceptan
- Nunca pases req.body directamente a metodos create o update del ORM
- Usa patrones de allowlist — selecciona explicitamente solo los campos que esperas
- Separa DTOs para operaciones de creacion vs actualizacion para limitar campos escribibles por accion
Tecnologías Afectadas
Data Hogo detecta esta vulnerabilidad automáticamente.
Escanea Tu Repo GratisVulnerabilidades Relacionadas
Condicion de Carrera en Pagos
highOperaciones de lectura-modificacion-escritura en pagos sin transacciones de base de datos permiten a los atacantes explotar ventanas de tiempo y gastar el mismo saldo multiples veces.
Manipulacion de Precios
criticalAceptar precios del cliente en vez de buscarlos del lado del servidor permite a los atacantes modificar requests de checkout y comprar productos al precio que elijan.
Feature Flags Expuestos
lowFeature flags incluidos en el bundle de JavaScript del frontend revelan funciones no lanzadas, configuraciones internas de testing y superficies de ataque potenciales a cualquiera que inspeccione el codigo.
Rutas de Debug en Produccion
mediumRutas de desarrollo y testing como /debug, /test, /seed o /api/dev dejadas activas en produccion exponen datos internos, bypassean autenticacion o permiten manipulacion de estado.