Checklist de defensa frente a SSRF
Puntúa tus defensas frente a la falsificación de peticiones del lado del servidor (SSRF) y exporta un informe de endurecimiento priorizado.
Abrir la herramienta →La herramienta interactiva se abre en inglés.
Puntúa tus defensas frente a la falsificación de peticiones del lado del servidor (SSRF, Server-Side Request Forgery). Recorres un checklist agrupado de mitigaciones reales (lista de permitidos de URL, bloqueo de la dirección de metadatos de la nube 169.254.169.254, de los rangos link-local y de los rangos privados RFC 1918, validación de la IP resuelta frente al DNS rebinding, seguridad ante redirecciones, IMDSv2 y filtrado del tráfico saliente en la capa de red), marcas cada una como cumplida, parcial o no cumplida, y obtienes una puntuación de cobertura ponderada, una remediación priorizada (primero las brechas críticas) y un informe de endurecimiento en texto plano que puedes copiar o descargar. SSRF figura en el OWASP Top 10 como A10:2021. Es una autoevaluación educativa: no hace ninguna petición de red, no resuelve nombres de host y no tiene capacidad de obtener URL, así que no puede realizar ni probar SSRF contra ningún sistema. Todo se ejecuta en tu navegador y nada de lo que marcas se sube ni se guarda en un servidor. Evalúa, endurece y prueba las defensas frente a SSRF solo en sistemas que te pertenezcan o que tengas autorización expresa para probar. Es una herramienta Pro: con una cuenta gratuita tienes 3 usos de herramientas Pro en total y después necesitas Pro.
- Recorre los grupos del checklist: validación y lista de permitidos, bloqueo de metadatos y rangos privados, DNS rebinding y redirecciones, IMDSv2 y filtrado de salida.
- Marca cada mitigación como cumplida, parcial o no cumplida.
- Revisa la puntuación de cobertura y la remediación priorizada, empezando por las brechas críticas.
- Copia o descarga el informe de endurecimiento y valida tus defensas con pruebas autorizadas.
Preguntas frecuentes
¿Qué es la falsificación de peticiones del lado del servidor (SSRF)?
La falsificación de peticiones del lado del servidor (SSRF) es una vulnerabilidad en la que un atacante consigue que un servidor envíe peticiones HTTP (u otras) a un destino que elige el atacante. La aplicación recibe una URL o un nombre de host (a menudo de una entrada del usuario, como el destino de un webhook, una función de «obtener esta imagen», una vista previa de PDF o URL o un campo de importar desde URL) y el servidor la solicita obedientemente. Como la petición sale del servidor, puede llegar a servicios internos, endpoints de metadatos de la nube y otros recursos no expuestos a internet, saltándose los controles del perímetro de red. SSRF figura en el OWASP Top 10 (A10:2021).
¿Cómo se previene el SSRF?
No hay un interruptor único: la prevención del SSRF es por capas. Valida y canonicaliza las URL que aporta el usuario e impón una lista de permitidos de hosts y esquemas en lugar de una lista de denegados. Resuelve el nombre de host y valida la IP resuelta real frente a un conjunto denegado (link-local y metadatos, loopback, rangos privados RFC 1918 y otros rangos de uso especial), y después conéctate a esa IP validada para que el DNS no pueda cambiar entre la comprobación y la conexión. Desactiva el seguimiento de redirecciones HTTP o vuelve a validar tras cada redirección. En AWS, exige IMDSv2 para que un simple GET por SSRF no pueda leer las credenciales de la instancia. Por último, aplica filtrado de salida en la capa de red y aísla el servicio que hace las peticiones, para que la comprobación de la capa de aplicación no sea lo único que separa a un atacante de tu red interna. Este checklist recorre cada uno de esos controles.
¿Por qué 169.254.169.254 es un objetivo tan habitual de SSRF?
169.254.169.254 es la dirección link-local del servicio de metadatos de instancia (IMDS) en AWS, GCP, Azure y otros. Un servidor que se ejecuta en la nube puede consultarlo para leer la configuración de la instancia y, sobre todo, credenciales IAM o de rol temporales. Si un atacante consigue que un servidor vulnerable solicite http://169.254.169.254/latest/meta-data/iam/security-credentials/ (en AWS IMDSv1), la respuesta devuelve credenciales de nube activas, y así es como muchos hallazgos de SSRF escalan a un compromiso total de la cuenta en la nube. Bloquear todo el rango link-local 169.254.0.0/16 en las capas de validación y de salida, y exigir IMDSv2 (que necesita un token de sesión y un límite bajo de saltos IP que un GET por SSRF simple no puede cumplir), son las dos defensas que más importan aquí.
¿Qué diferencia hay entre el SSRF básico y el ciego?
En el SSRF básico (o en banda), la respuesta de la petición falsificada se devuelve al atacante, que puede leer directamente páginas internas, metadatos o respuestas de servicios. En el SSRF ciego, la respuesta no se refleja (el atacante no la ve), pero el servidor sigue haciendo la petición. El SSRF ciego sigue siendo peligroso: puede usarse para escanear puertos y cartografiar la red interna midiendo los tiempos de respuesta, para lanzar peticiones que cambian el estado de servicios internos o para exfiltrar datos por canales laterales como devoluciones de llamada DNS/HTTP fuera de banda. Como el impacto no depende de ver la respuesta, los mismos controles preventivos (lista de permitidos, validación de IP y filtrado de salida) se aplican a los dos.
¿Esta herramienta prueba mi sitio frente a SSRF o hace alguna petición?
No. Es solo una referencia educativa y una autoevaluación. Funciona íntegramente en tu navegador, no hace llamadas de red de ningún tipo, no resuelve nombres de host y no tiene capacidad de obtener URL, así que no puede usarse para realizar ni probar SSRF contra ningún sistema, incluido el tuyo. Solo puntúa las mitigaciones que marcas y monta un informe de endurecimiento con tus respuestas. Valida tus defensas reales con pruebas autorizadas sobre sistemas que te pertenezcan o que tengas permiso para probar.
¿Es gratis?
No, es una herramienta Pro. Con una cuenta gratuita tienes 3 usos de prueba de herramientas Pro en total; después necesitas Pro.