LecturaBienvenida al curso
Bienvenido a OWASP A10: falsificación de solicitudes del lado del servidor (SSRF). Suponga una aplicación ficticia de clasificados que, cuando usted pega un enlace, muestra una vista previa con el título y la imagen de la página. Para eso, el servidor descarga la URL por usted. Ahora alguien pega esta otra:
http://169.254.169.254/latest/meta-data/iam/security-credentials/rol-app-webDesde su casa, esa dirección no lleva a ningún lado. Desde una máquina virtual en AWS con la versión vieja del servicio de metadatos (IMDSv1), devuelve un JSON con AccessKeyId, SecretAccessKey y Token: las credenciales temporales del rol del servidor. La "vista previa" se las enseña a quien las pidió. Nadie entró al servidor; el servidor hizo la solicitud solito. Eso es una SSRF. En la lección 3 verá un caso público de 2019 donde esta cadena terminó en la filtración de datos de un banco.
Qué va a lograr
- Explicar qué es una SSRF, por qué ocurre y por qué es tan grave en la nube.
- Reconocer en código Python y Node el patrón fuente y sumidero que la produce.
- Revisar un repositorio con un procedimiento repetible y apoyado en
grep. - Corregir la falla con listas de permitidos, validación de URLs y verificación de la IP resuelta.
- Endurecer la infraestructura con segmentación, proxy de egreso, IMDSv2 y mínimo privilegio.
- Detectar intentos en registros, escribir una alerta y redactar un reporte de hallazgo.
Para quién es y qué necesita
Para quien desarrolla o analiza seguridad y ya conoce lo básico de la web. Conviene haber hecho Seguridad web con OWASP Top 10; leer Python sencillo ayuda, aunque cada función se explica al aparecer. Necesita Python 3.10 o superior, una terminal (bash o PowerShell), curl y un editor. No necesita cuenta en ninguna nube: el servicio de metadatos se simula con una pequeña app Flask en su propia máquina.
Cómo está organizado
| Módulo | Qué aprende | Laboratorio |
|---|---|---|
| 1. Qué es SSRF y por qué pasa | Concepto, historia, metadatos de la nube e IMDSv2, variantes e impacto | Mapa de funciones que hacen solicitudes salientes |
| 2. Cómo se ve en el código y cómo se revisa | Fuentes y sumideros, por qué fallan las listas de bloqueo, revisión de código | Su propia aplicación vulnerable en localhost |
| 3. Cómo se previene y se corrige | Listas de permitidos, urlsplit, resolución DNS, rangos internos, red y nube | Corregir la aplicación y probarla con pytest |
| 4. Detectar, monitorear y reportar | Qué registrar, indicadores, reglas Sigma, alcances del WAF y la conclusión | Detectar intentos y reportar el hallazgo |
| Evaluación | 6 preguntas sobre todo el curso | Aprueba con 70 % |
Cómo aprovecharlo
El laboratorio del módulo 2 pide tres terminales: una para el servicio interno simulado, otra para la app vulnerable y otra para curl, con el entorno virtual activo en las dos primeras. Olvidar activarlo es el tropiezo más común. El del módulo 3 es el que más cuesta, porque la primera corrección que se le ocurre a casi todo el mundo, bloquear 169.254.169.254 y localhost, se cae con un 127.1 o con un dominio que resuelve a una IP interna. Sus pruebas en pytest le harán ver caer su lista de bloqueo antes de escribir la de permitidos. Al aprobar la evaluación final con 70 % recibe el certificado y la insignia.
Tiempo estimado
Unas 4 horas y media. Los laboratorios de los módulos 2 y 3 trabajan sobre la misma carpeta lab-ssrf: guárdela.