Pedido Ajeno
IDOR / Broken Access Control
// OBJETIVO
Leer el pedido de otro usuario cambiando el ID en la petición, hasta llegar al del admin.
// ZONA DE ATAQUE
Corre en un iframe de origen opaco: no puede leer este sitio ni tu progreso. Cuando logres el exploit, la flag aparece dentro de la app — copiala y verificala.
// CONSULTÁ
Pistas
Código vulnerable
El endpoint busca por ID y responde sin verificar la pertenencia:
app.get('/api/orders/:id', (req, res) => {
const order = db.orders.get(req.params.id); // ← solo mira el ID
if (!order) return res.status(404).json({ ok: false });
res.json({ ok: true, order }); // sin chequear order.owner
});El identificador es predecible y no hay control de acceso: cualquier usuario
autenticado puede pedir /api/orders/1 y leer el pedido de otro. Es un IDOR
clásico (Insecure Direct Object Reference), la raíz de muchos broken access
control.
Remediación
Verificá que el recurso pertenezca a quien lo pide (o que tenga permiso):
const order = db.orders.get(req.params.id);
if (!order) return res.status(404).json({ ok: false });
+ if (order.owner !== req.session.userId) {
+ return res.status(403).json({ ok: false }); // no es tuyo
+ }
res.json({ ok: true, order });Por qué funciona: el chequeo order.owner === req.session.userId ata cada
recurso a su dueño, así que enumerar IDs ajenos devuelve 403 en vez de datos.
El control de acceso se decide en el servidor con la identidad de la sesión,
nunca con lo que el cliente elige pedir.