Fundamentos de ataques web

Casi todos los ataques web se apoyan en una idea: el servidor no debe fiarse de nada que venga del cliente. Para verlo hay que saber leer y modificar lo que viaja entre navegador y servidor. Este módulo construye esa base.

1. Anatomía de HTTP

Cada interacción es una petición del cliente y una respuesta del servidor, con la misma estructura: una línea inicial, unas cabeceras y un cuerpo opcional, separados de las cabeceras por una línea en blanco.

$ GET /ruta HTTP/1.1
Host: objetivo
User-Agent: curl/8.0
Cookie: sesion=abc123

(cuerpo vacío en un GET)

$ curl -i http://objetivo/ruta
HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html
Set-Cookie: sesion=abc123; HttpOnly

<html>...

2. HTTP no tiene estado: el papel de las cookies

Una idea que hay que tener clarísima: HTTP es sin estado. El servidor no recuerda nada de una petición a la siguiente; cada petición llega "de cero". Entonces, ¿cómo sabe una web que ya has iniciado sesión? Porque tras el login te entrega una cookie de sesión (un identificador) y tu navegador la reenvía automáticamente en cada petición. Esa cookie es tu sesión.

De ahí salen dos familias enteras de ataques que verás en el módulo 8: si un atacante roba esa cookie (por ejemplo con un XSS), se convierte en ti sin saber tu contraseña; y si el navegador la reenvía automáticamente incluso en peticiones originadas por otra web, aparece el CSRF. Los atributos de la cookie (HttpOnly, Secure, SameSite) existen precisamente para contener esos dos riesgos.

3. El principio de confianza: qué controla quién

El fundamento de casi todo ataque web cabe en una frase: el servidor no debe fiarse de nada que venga del cliente. Todo lo que llega del navegador —parámetros de URL, cuerpo del formulario, cookies, cabeceras, y hasta el JavaScript que tú mismo serviste— es entrada del usuario y se puede ver y cambiar. Un campo <input type="hidden"> con el precio no es "oculto" para nada: viaja al cliente y vuelve modificable.

4. El modelo de mismo origen (SOP) y CORS

El navegador aísla las webs entre sí con la política de mismo origen (Same-Origin Policy): el JavaScript de a.com no puede leer las respuestas de b.com. Un "origen" es la terna esquema + dominio + puerto; si cualquiera de los tres difiere, es otro origen. Esta es la barrera que impide que una web maliciosa lea tu correo abierto en otra pestaña.

CORS (Cross-Origin Resource Sharing) es el mecanismo por el que un servidor puede relajar esa barrera a propósito, para permitir que ciertos orígenes sí lean sus respuestas (típico en APIs). Mal configurado —por ejemplo devolviendo Access-Control-Allow-Origin reflejando cualquier origen y con credenciales— abre justo el agujero que la SOP cerraba. Entender esta pareja es clave para el módulo siguiente.

5. Herramientas para observar y modificar

• DevTools del navegador (F12): pestaña Red para ver cada petición y respuesta, Elementos para el HTML final, Fuentes para leer el JavaScript.
• curl: -i muestra las cabeceras de respuesta, -X cambia el método, -H añade cabeceras, -d envía cuerpo, -b envía cookies. Ideal para automatizar y para scripts.
• Proxy de interceptación (Burp Suite): la herramienta central del pentesting web. Se coloca entre el navegador y el servidor y te deja pausar cada petición y modificarla antes de que salga. Su módulo Repeater reenvía una petición una y otra vez con cambios; Intruder la automatiza. Es la diferencia entre observar y experimentar.

$ curl -i http://objetivo/

$ curl -i -X POST -d 'campo=valor' http://objetivo/ruta

$ curl -H 'X-Cabecera: valor' -b 'cookie=valor' http://objetivo/ruta

Un detalle que atrapa a todo el mundo: el navegador sigue las redirecciones (3xx) sin enseñártelas. Con curl -i sin -L —o interceptando con Burp— ves la respuesta intermedia tal como llega, con sus cabeceras, que a veces es donde está lo interesante.

6. Debilidades básicas y dónde se esconden

7. Marco de referencia: OWASP Top 10

El OWASP Top 10 es la lista consensuada de las diez categorías de riesgo más críticas en aplicaciones web; se actualiza cada pocos años y es el vocabulario común del sector. Sirve para dos cosas: ponerle nombre a lo que encuentras y ordenar el informe de forma que el cliente lo entienda. Categorías que tocaremos en este curso: Broken Access Control (control de acceso roto, la nº 1), Injection (módulos 6-7), Security Misconfiguration, Identification and Authentication Failures (módulos 8, 12) y Cryptographic Failures. Lo de este módulo encaja sobre todo en control de acceso roto, configuración incorrecta y diseño inseguro.

8. Método de trabajo

1. Recorre toda la aplicación como un usuario normal, con el proxy grabando (así construyes el mapa del sitio y su historial de peticiones).
2. Lee el código fuente y los ficheros JavaScript: rutas, endpoints de API, comentarios.
3. Para cada petición pregúntate lo mismo: ¿qué controla el usuario aquí y qué asume el servidor?
4. Modifica un elemento cada vez (un parámetro, una cookie, el método) y compara la respuesta con la original.
5. Anota todo, aunque no parezca útil todavía: en web, la vulnerabilidad suele ser la suma de dos detalles pequeños.

Autoevaluación

1. Si HTTP no tiene estado, ¿cómo sabe una web que ya has iniciado sesión?
2. ¿Por qué un campo hidden de un formulario no es un mecanismo de seguridad?
3. Define "origen" en la política de mismo origen. ¿http://a.com y https://a.com son el mismo origen?
4. ¿Para qué sirve CORS y qué pasa si un servidor refleja cualquier origen con credenciales?
5. ¿Qué diferencia hay entre una respuesta 403 y una 404 desde el punto de vista de un auditor?
6. ¿Por qué el navegador no te muestra una respuesta 302 y curl -i sí?
7. Una aplicación guarda el rol del usuario en una cookie. ¿Qué debería hacer en su lugar y por qué?