El hacking web no es lanzar exploits al azar: es un proceso ordenado. Una metodología te asegura repetir siempre los mismos pasos y no dejar partes de la aplicación sin revisar. Apóyate en marcos reconocidos como la OWASP Web Security Testing Guide (WSTG).
Las fases, en orden
- Reconocimiento. Descubrir tecnología (servidor, framework, CMS), subdominios, endpoints y archivos expuestos (
robots.txt,sitemap.xml). - Mapeo de la aplicación. Recorrer cada página, formulario, cookie y parámetro. Un proxy de interceptación como Burp Suite registra todo el tráfico y arma el árbol del sitio.
- Identificación de la superficie de ataque. Marcar cada punto donde entran datos del usuario: parámetros de URL, campos de formulario, cabeceras, cookies, cuerpos JSON.
- Pruebas dirigidas. Sobre cada entrada, probar las clases de fallos (inyección, XSS, control de acceso, etc.).
- Explotación y evidencia. Confirmar el fallo con una prueba de concepto, sin causar daño.
- Reporte. Documentar riesgo, impacto y remediación (último tema del pilar).
Regla mental clave
Donde el usuario puede introducir datos, hay que probar. Cada entrada que la aplicación no valida es una posible puerta. Mapear primero todas las entradas evita atacar a ciegas.
Herramientas típicas de esta fase
| Herramienta | Para qué |
|---|---|
| Burp Suite / OWASP ZAP | Proxy: ver, interceptar y modificar el tráfico |
| ffuf / dirsearch | Descubrir rutas y archivos ocultos (fuzzing) |
| whatweb / Wappalyzer | Identificar tecnologías del sitio |
| DevTools del navegador | Inspeccionar peticiones, cookies y JavaScript |
Con la aplicación mapeada y la superficie de ataque clara, el siguiente paso es atacar cada entrada. Empezamos por la falla más conocida: la inyección SQL, el próximo tema del pilar.