Contenido del lab

Escenario

Drivia es un clon de Google Drive: subes, organizas, previsualizas, compartes y descargas ficheros. La víctima, Laura Giménez (victima@drivia.local), guarda un fichero privado con su frase de recuperación dentro de Mi unidad › Personal › Privado. Esa frase es la flag.

Tú eres el atacante attacker@drivia.local / password123. Consigue el contenido de ese fichero privado sin ser Laura. Hay tres vías independientes.

Qué tienes

• Tu cuenta de atacante con tus propios ficheros (punto de partida, no es el fallo).
• El visor de ficheros, la descarga, el compartir por correo/enlace y la previsualización.

Guía paso a paso

1. Recon. Abre uno de tus ficheros y mira el proxy: el visor lanza GET /api/files/:id (ficha + contenido), GET /api/files/:id/preview?res=<nombre> (renderizador) y el botón de descarga usa GET /api/files/:id/download/<nombre>. Ahí están las tres superficies.

2. Vía 1 — IDOR. La ficha se pide por un id numérico correlativo y el endpoint no comprueba de quién es el fichero. Cambia el :id por uno que no sea tuyo (la respuesta trae owner_id, así sabes que es de otro) hasta leer el fichero de la víctima con la flag.

3. Vía 2 — Web Cache Deception. La descarga sí valida el acceso (te da 403 sobre el fichero ajeno), pero delante hay un "CDN" que cachea por extensión estática ignorando cookies. La URL …/download/algo.png sigue sirviendo el fichero (path confusion) y se cachea. En el diálogo Compartir hay "Copiar enlace de descarga": pásaselo a la víctima; cuando ella lo abre (autenticada), su respuesta queda en la caché compartida (cabecera X-Cache: HIT) y tú la lees.

4. Vía 3 — LFI / Path Traversal. El parámetro res del renderizador se une a la carpeta del fichero sin sanear. Previsualiza un fichero tuyo y pon res=../../../../etc/passwd (lectura arbitraria) o res=../<owner_id>/<file_id> para leer el fichero de la víctima (el owner_id y el file_id los sacas del IDOR).

5. Captura la flag. Por cualquiera de las tres vías obtienes la frase de recuperación del fichero privado: FLAG{…}.

Canales de feedback (no vuelas a ciegas)

• La respuesta de la ficha incluye owner_id: sabes cuándo estás leyendo el fichero de otra cuenta.
• La descarga responde 403 a terceros y las cabeceras X-Cache/CF-Cache-Status te dicen si una URL vino de la caché.
• El renderizador devuelve el contenido bruto del recurso que pidas en res, así ves de inmediato el efecto del traversal.

Decoys (descártalos por razonamiento)

• El enlace por token opaco (/d/<token>) es el camino seguro: valida el token, no un id adivinable. No es la vía de ataque.
• La lista de "Mi unidad" solo enseña tus ficheros: la app oculta los ajenos en el listado, pero la API del visor no los protege (ahí está el IDOR).
• Necesitas un fichero tuyo como puerta al renderizador; el traversal ocurre en res, no en el :id.

La falla del laboratorio

Clases: IDOR / referencia directa a objeto insegura (CWE-639), Web Cache Deception (CWE-525) y Path Traversal (CWE-22), todas con divulgación de información (CWE-200). OWASP A01:2021 (Broken Access Control) + A05:2021 (Security Misconfiguration).

Las tres vías comparten la raíz: el servidor confía en algo que el atacante controla en lugar de comprobar la autorización por objeto en cada punto. El visor sirve por id sin verificar propiedad/compartición; el borde cachea por la forma de la URL sin variar por sesión; y el renderizador construye una ruta de disco a partir de la entrada del usuario. La defensa correcta: autorización a nivel de objeto en cada acceso (e identificadores opacos), cachear solo respuestas marcadas públicas variando por sesión, y nunca usar entrada del usuario como ruta (resolver y comprobar contención dentro del directorio permitido).

Laboratorio basado en la reproducción anonimizada (empresa ficticia Drivia) de técnicas reales de bug bounty sobre acceso a ficheros privados.