Nuevos labs cada semana — Accede a todos desde 7,99€/mes

Ver labs →
BBLABS v2BBLABSv2
>Inicio>Labs
>New labs

Últimos 3 labs

Cargando…

Ver todos los labs →
>Creators>Ranking
>Aprender

Aprender bug bounty

AcademyGuías, cheatsheets y diccionarioVulnerabilidadesXSS, SQLi, IDOR, SSRF y másRoadmapTu ruta de bug bounty paso a pasoBlogGuías y noticias de bug bounty
>Empresa>Precios
LinkedInInstagramYouTubeDiscordContáctanos
AccederAcceder
>Inicio>Labs>New labs>Creators>Ranking>Aprender>Empresa>Precios
Iniciar SesiónCrear Cuenta
  1. Inicio
  2. Labs
  3. Web Cache Deception & BAC in /uploads
DifícilVDP1h

Contacto

Practica, aprende y hackea

Plataforma de práctica de bug bounty con labs basados en reportes reales. Aprende hacking ético en entornos seguros.

contactar→

Síguenos

YouTube
@0xGorka
X
@gorkaelbochi
LinkedIn
gorka-el-bochi-morillo
Instagram
@_.gorkaaa.b
Email
team@bblabs.es

Accede a todos los labs desde 7,99€/mes

Nuevos labs cada semana. Cancela cuando quieras.

Crear cuenta

BBLabs es la plataforma de laboratorios de bug bounty en español donde aprender bug bounty con vulnerabilidades reales extraídas de reportes pagados en HackerOne, Bugcrowd e Intigriti. Aquí practicas hacking web —XSS, SQLi, IDOR, SSRF, CSRF y más— en entornos descargables, capturas la flag, lees el writeup y aplicas la técnica en programas activos de bug bounty.

BBLabs es la alternativa en español a HackTheBox, TryHackMe y PentesterLab para quienes quieren practicar bug bounty con reportes reales en lugar de CTFs artificiales. Desde 7,99€/mes, sin permanencia.

→ Aprender bug bounty desde cero→ Reportes de bug bounty reales→ BBLabs para empresas y academiasLabsAcademyVulnerabilidadesRanking de huntersLabs de XSSLabs de IDORLabs de SSRFLabs de CSRFHackTheBox alternativaHack4u alternativaTryHackMe alternativaPortSwigger alternativaPentesterLab alternativaBug Bounty Labs comparativaMejores plataformas bug bounty 2026BlogSpoilers¿Qué es el bug bounty?¿Cuánto se gana en bug bounty?OWASP Top 10 explicadoMejores webs para practicar hacking web
Hecho cony código
TérminosPrivacidadComparativa

© 2026 BBLABS v2 — Todos los derechos reservados

Web Cache Deception & BAC in /uploads

Por @gorka

E-commerce ficticio que encadena dos fallos: una SPA en React que decide el rol del usuario leyendo `GET /api/auth/me` (CWE-602), y un middleware de cache propio que normaliza la query string (strip de `utm_*`, `ref`, `cb`, `_`, `t`), no varía sobre `Authorization`/`Cookie`, e ignora `Cache-Control: private, no-store` (CWE-524). Un bot interno de soporte (Puppeteer-core) navega URLs same-origin con cookies de admin, lo que permite sembrar el cache con la respuesta privilegiada y leerla anónimamente.

98 visitas13 completadosActualizado jun 2026
Iniciar sesión para empezar
Vídeo explicativopor @gorka

Accede a este lab

Entorno seguro y aislado

Crea una cuenta y suscríbete para acceder a todos los labs. Practica en un entorno real y seguro.

Crear cuentaYa tengo cuenta

Hunters que lo han resuelto· 8

pl4nkton1
@pl4nktonHace 18 días
AL2
@alndrwlaHace 18 días
pmartinezr3
@pmartinezrmay 2026
0xyo
@0xyomay 2026
MA
@maxioliveramay 2026
DO
@doco453may 2026
w4tchw0lf
@w4tchw0lfmay 2026
gorka
@gorkamay 2026

Objetivos

1
Identificar que la SPA decide el rol UI
2
Descubrir desde el panel admin (renderizado tras el bypass) la URL del recurso sensible
3
nalizar las cabeceras `X-Cache` y `X-Cache-Key` para mapear cómo el normalizador del cache
4
Localizar el gadget same-origin: el formulario `/support` con el campo `screenshot_url`
5
Encadenar el ataque enviando un ticket cuyo `screenshot_url` apunte a....
6
Extraer la flag del PDF filtrado

Información

Dificultad
Difícil
Duración
1h
Bounty
VDP
Completados
13
Creador
gorka@gorka
Actualizado
jun 2026

Logro que recibirás

Cuando resuelvas este lab desbloqueas este logro compartible

BBLABS.ESLab Resuelto
DifícilVDP
// achievement_unlocked

Web Cache Deception & BAC in /uploads

Auth BypassBAC
jun 2026
gorka
solved_by@gorkaMiembro desde mar 2026
bblabs.es// real bug bounty practice

Writeups de la comunidad

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".

Acceso al Lab File

Suscríbete para descargar

Crear cuenta

Herramientas

Burp SuiteNavegador

Prerequisitos

  • Conocimiento de HTTP caching
  • Soltura con Burp Suite
  • Familiaridad con SPAs en React

Tags

Auth BypassBAC