IDOR: el ataque de cambiar un número
Lab quirúrgico sobre el bug de autorización más común: pedir el recurso de otro cambiando un id en la URL. Con diagrama y quiz.
Antes de empezar necesitás
- Saber qué es un endpoint y un token (lab: JWT no es autorización)
Al terminar vas a poder
- Reconocer un IDOR a partir del diseño de un endpoint
- Distinguir 'token válido' de 'acción permitida'
- Nombrar el chequeo que lo previene
El IDOR (Insecure Direct Object Reference) no necesita romper nada criptográfico. Es, literalmente, cambiar un número en la URL y recibir el dato de otra persona. Por eso es tan común: el atacante usa la app exactamente como fue diseñada.
El ataque, en un diagrama
sequenceDiagram actor A as Atacante (user_42) participant API participant DB Note over A,API: Token válido de user_42 A->>API: GET /facturas/100 (su id) API->>DB: buscar factura 100 DB-->>API: factura de user_42 API-->>A: 200 OK ✔ (correcto) A->>API: GET /facturas/101 (id ajeno) API->>DB: buscar factura 101 DB-->>API: factura de OTRO usuario API-->>A: 200 OK ✘ IDOR
El token nunca se rompió. user_42 está perfectamente autenticado. El problema es que el servidor sirvió el recurso sin chequear que fuera suyo.
El chequeo que falta
GET /facturas/{id}
función obtener_factura(request, id):
usuario = validar_token(request) # authn ✓
factura = db.buscar(id)
si factura.owner_id != usuario.id: # ← authz: el chequeo clave
responder 404 # 404, no 403: no revela que existe
responder 200, facturaUna condición. Eso es lo que separa un endpoint seguro de un IDOR. Y es justo lo que falta cuando alguien asume que “con login alcanza”.
Probarlo (en tu propio sistema)
# Con tu token, pedí un id que NO es tuyo. ¿Responde 200 o 404?
curl -s -o /dev/null -w "%{http_code}\n" \
-H "Authorization: Bearer $TOKEN" \
https://api.tuapp.local/facturas/101Quiz
Comprobá lo que entendiste
0 / 2 correctas
-
1. ¿Cuál es la causa raíz de un IDOR?
-
2. Un endpoint devuelve 200 al pedir el id de otro usuario con un token válido. ¿Qué es?
Lo que practicás en este lab
Llevátelo a tu repo si querés, pero no es obligatorio: es tu aprendizaje.
- Captura del quiz
- Pseudocódigo del chequeo de ownership que agregarías a un endpoint tuyo
Reto
Tomá un endpoint de un proyecto tuyo que reciba un id en la URL. Escribí el chequeo de ownership que le falta (o confirmá que ya lo tiene) en 3 líneas de pseudocódigo.
Resolvelo y escribí dos líneas explicando qué pasó. Con eso lo fijás.