Saltearse al contenido

Metodología web

Un test web ordenado evita puntos ciegos y hace el trabajo reproducible. Esta es la secuencia que siguen la mayoría de engagements y programas de bug bounty, alineada con la OWASP Web Security Testing Guide (WSTG) y el PTES. Cada vulnerabilidad concreta tiene su ficha; aquí está el marco que las une y el orden en que conviene atacarlas.

Antes de tocar nada, fija por escrito:

  • En alcance / fuera de alcance: dominios, subdominios, IPs, APIs, apps móviles.
  • Exclusiones: acciones destructivas, DoS, datos reales de terceros, envío de correos masivos, ingeniería social.
  • Ventanas horarias, datos de prueba, cuentas facilitadas y límites de volumen (no enumerar millones de IDs).
  • Contacto de emergencia y procedimiento si encuentras algo crítico (p. ej. datos expuestos) o si tiras un servicio sin querer.

Todo lo que sigue se hace solo dentro de ese alcance autorizado.

  • Pasivo (ver área 01, sin tocar el objetivo): dominios y subdominios (crt.sh, subfinder, amass), ASN/rangos, tecnologías, correos y empleados, repos y secretos filtrados, histórico (Wayback), buckets.
  • Activo: resolución y httpx para ver qué responde, fingerprint de stack (servidor, framework, WAF, CMS con whatweb/wafw00f), puertos relevantes.
  • Descubrimiento de contenido: ffuf/feroxbuster con wordlists (SecLists, raft, por tecnología), ficheros sensibles (.git, .env, backups), rutas de API.
  • Proxyear todo por Burp y recorrer la app como usuario real (todos los roles).
  • Inventariar parámetros (arjun, paramspider), endpoints de API, flujos (registro, login, recuperación, pago), roles y permisos, y puntos de entrada (formularios, cabeceras, cookies, uploads, WebSockets).
  • Identificar tecnologías por componente (motor de plantillas, ORM, serialización, CMS) porque condicionan qué fallos probar.

4. Análisis por categorías (WSTG / OWASP Top 10)

Sección titulada «4. Análisis por categorías (WSTG / OWASP Top 10)»

Recorre sistemáticamente, priorizando por impacto:

  • Control de acceso (IDOR/BOLA, escalada vertical, mass assignment) — suele ser el más rentable.
  • Autenticación y sesión (enumeración, fuerza bruta, MFA, reset, fixation).
  • Inyecciones (SQLi, NoSQLi, command, SSTI, XXE, LDAP).
  • Cliente (XSS, CSRF, clickjacking, CORS, prototype pollution).
  • Server-side avanzado (SSRF, deserialización, LFI/RFI, request smuggling, cache poisoning).
  • Lógica de negocio (fraude, saltos de flujo, race conditions).
  • Configuración (cabeceras de seguridad, métodos HTTP, exposición de información, componentes con CVEs conocidos).

Demuestra el impacto real con una PoC mínima y reproducible, sin dañar ni exfiltrar datos reales de terceros. Encadena fallos cuando multipliquen el impacto (IDOR + JWT, XSS + CSRF, SSRF + metadatos cloud, open redirect + OAuth). Documenta cada paso con peticiones/respuestas y capturas.

Asigna severidad con CVSS (vector + score) y traduce a impacto de negocio (qué datos, cuántos usuarios, qué daño). Prioriza para el cliente lo explotable y de alto impacto sobre lo teórico.

Cada hallazgo: título, severidad (CVSS), descripción, impacto de negocio, pasos de reproducción detallados, evidencia (peticiones/capturas) y remediación concreta y accionable. Añade un resumen ejecutivo no técnico. Un buen reporte es la mitad del trabajo (ver área 20, Bug Bounty).

Tras la corrección, reverifica cada hallazgo y documenta si quedó resuelto, mitigado o sigue abierto.

Recon subfinder, amass, httpx, whatweb, wafw00f, nuclei, crt.sh, gau/waybackurls
Contenido ffuf, feroxbuster, dirsearch, SecLists
Mapeo Burp Suite (proxy), arjun, paramspider
Explotación Burp (Repeater/Intruder/Turbo Intruder), sqlmap, dalfox, commix, jwt_tool
Apoyo PayloadsAllTheThings, HackTricks, DevTools del navegador

El mismo recorrido sirve para auditar defensivamente: revisar controles de acceso, validación de entrada/salida, gestión de sesión, cabeceras de seguridad, logging y capacidad de detección de cada ataque. Cada ficha incluye su sección Blue Team con detección, telemetría y hardening.