Lab 1: Recon completo sobre un programa simulado

01Objetivo del lab

Aplicar los módulos 2-5 (scope, recon pasivo, recon activo, priorización) sobre un objetivo real y controlado, sin aún intentar explotar nada. El entregable de este lab es un mapa de superficie priorizado, no una vulnerabilidad.

02Objetivo simulado: GhostGram

GhostGram es la app de la serie Ghost que simula una red social (perfiles, feed, mensajería, subida de avatares). Para este lab se trata como un programa de bug bounty con su propia policy simulada:

Scope (simulado):

• In-scope: toda la aplicación web de GhostGram y su API (/api/*).
• Out-of-scope: rate limiting, problemas de UX sin impacto de seguridad, cualquier endpoint de analítica/telemetría de terceros si los hubiera.
• Severidad mínima: se admite cualquier severidad, pero self-XSS sin posibilidad de entrega a otra víctima se considera informativo, no premiado.

03Pasos del lab

1. Lee la policy simulada como si fuera real. Anota qué queda fuera antes de tocar nada (módulo 2).
2. Recon pasivo primero, aunque el objetivo sea una app local: identifica stack tecnológico (inspecciona cabeceras HTTP, nombres de cookies, estructura de respuestas de error) como harías con Wappalyzer/Shodan en un objetivo real. Documenta qué te dice el stack sobre dónde buscar fallos conocidos.
3. Crea dos cuentas de usuario distintas (rol idéntico, usuario A y usuario B). Esto es imprescindible para cualquier prueba de control de acceso horizontal — sin una segunda cuenta no se puede demostrar un IDOR real, solo sospecharlo.
4. Navega la app completa con proxy interceptando, cubriendo: registro, login, edición de perfil, subida de avatar, feed, publicar contenido, comentar, mensajería directa, configuración de cuenta, cualquier función de "compartir" o "exportar". Anota cada endpoint con método, parámetros y tipo de ID.
5. Analiza el JavaScript del cliente en busca de rutas de API que no aparecen al navegar manualmente (módulo 4). GhostGram, como toda SPA, filtra en el bundle más rutas de las que la UI expone.
6. Clasifica cada endpoint encontrado según las señales de prioridad del módulo 5: ¿tiene ID predecible? ¿involucra a dos usuarios (seguir, bloquear, mensajear, comentar en perfil ajeno)? ¿maneja un recurso subido por el usuario (avatar, imagen de post) que podría cachearse o servirse mal?

04Entregable del lab

Una tabla (formato libre: hoja de cálculo o markdown) con columnas: endpoint, método, rol mínimo observado, tipo de ID, ¿involucra a otro usuario?, prioridad asignada (alta/media/baja) y justificación de una línea. Sin esta tabla no se pasa al módulo 7 — la explotación sin mapa priorizado es exactamente el error que el módulo 5 advierte evitar.

05Qué NO hacer en este lab

• No intentar explotar nada todavía. Este lab es puramente de reconocimiento y priorización.
• No asumir que "es un lab, así que todo vale": trátalo con la misma disciplina de scope que un programa real, para que el hábito se fije.

06Conexión con el resto del curso

Los endpoints de alta prioridad que identifiques aquí (especialmente los relacionados con avatares/subida de imágenes y con interacción entre usuarios) son exactamente los que se explotan en el módulo 7 (IDOR y control de acceso) usando este mismo objetivo.