Web Cache Deception & BAC in /uploads

Lumora Market es un mini e-commerce (Express + TypeScript + better-sqlite3 + React 18 + Vite + Puppeteer-core, puerto 2300) diseñado como playground para una cadena de dos vulnerabilidades reales:

• Capa 1 — Confianza ciega del cliente en la respuesta del servidor (CWE-602). La SPA hace GET /api/auth/me al cargar y persiste el role devuelto. El navbar y el routing del panel /admin se renderizan solo a partir de ese campo. Una regla de Burp que reescriba "role":"user" → "role":"admin" en la respuesta hace aparecer la UI de admin con la lista de "Internal Reports", incluyendo la URL /internal/credentials-report.pdf. Al pedirla directamente, el middleware requireAdmin del backend devuelve 403 — esa puerta es honesta. El bypass solo sirve como recon: revela el nombre del recurso sensible.

• Capa 2 — Web Cache Deception por normalización de la cache key (CWE-524). El middleware de cache propio (server/src/middleware/cache.ts) tiene tres defectos combinados: (a) reescribe la query string eliminando utm_*, ref, cb, _, t antes de calcular la key, (b) no incluye Authorization ni Cookie en la key (no hay vary por identidad), y (c) almacena toda respuesta 2xx durante 60 s ignorando Cache-Control: private, no-store que pone el origen. Resultado: dos URLs vistas como distintas por el origen (porque la cookie del bot autentica al admin) terminan en la misma bucket que la URL "limpia" anónima.

• Gadget — el bot de soporte. El formulario público /support admite un campo screenshot_url. El proceso server/src/bot/supportBot.ts (Puppeteer-core) hace login como admin con credenciales aleatorias por boot, polling de tickets status=new, lanza Chromium, setea lm_token=<JWT admin> como cookie en localhost, y hace page.goto(screenshot_url, { waitUntil: 'domcontentloaded' }). Rechaza orígenes que no sean los del propio lab (localhost:2300, 127.0.0.1:2300, lumora:2300), por lo que no es un SSRF clásico — pero sí un primitivo perfecto para envenenar el cache con la respuesta privilegiada del propio sitio.

La cadena completa:

1. Login como attacker@lumora.market / password123.
2. Burp Match & Replace sobre body de respuesta: "role":"user" → "role":"admin".
3. Recargar SPA → aparece /admin con la URL /internal/credentials-report.pdf.
4. Confirmar normalización con curl -i 'http://localhost:2300/internal/credentials-report.pdf?cb=test' y ver que X-Cache-Key: /internal/credentials-report.pdf (sin la query).
5. Abrir /support y enviar un ticket con screenshot_url: http://localhost:2300/internal/credentials-report.pdf?cb=poison.
6. Esperar ~10 s (ciclo de polling del bot). El bot navega la URL → el origen sirve el PDF al admin con Cache-Control: private, no-store → el middleware lo guarda igual bajo la key normalizada.
7. Anónimamente: curl -i http://localhost:2300/internal/credentials-report.pdf -o leaked.pdf → X-Cache: HIT, 200 OK.
8. pdftotext leaked.pdf - | grep -oE 'FLAG\{[a-f0-9]{32}\}' → flag.

Por qué encaja en la familia "Web Cache Deception". El paper original de Omer Gil (2017) abusa de un CDN que cachea por extensión /account.php/foo.css mientras el origen ignora la parte cosmética y devuelve la página sensible. Aquí el twist es el mismo en otra dirección: dos URLs (...?cb=poison y ...) son distintas para el origen (autenticación + branching) pero iguales para el cache (la query se descarta antes de keyear). Una víctima privilegiada visita la "ruidosa" y la víctima anónima cosecha la "limpia".