SSRF: qué es, dónde aparece y cómo se protege un servidor
Guía en castellano sobre server-side request forgery (SSRF): qué es, funciones donde suele esconderse, cómo se busca en bug bounty y cómo se corrige.
Qué es
En un SSRF (Server-Side Request Forgery) consigues que el servidor haga una petición a la dirección que tú eliges. El problema es que el servidor está dentro de la red de la empresa: llega a servicios internos, bases de datos de administración o al servicio de metadatos de la nube, cosas que desde Internet no se ven.
En la nube el caso clásico es la dirección 169.254.169.254, donde muchos proveedores sirven datos de la máquina y, en configuraciones antiguas, credenciales temporales.
Dónde suele aparecer
- Importar algo desde una URL: una imagen de perfil, un feed, un fichero.
- Vistas previas de enlaces en chats y redes sociales.
- Webhooks, integraciones y pruebas de conexión ("comprobar que esta URL responde").
- Generadores de PDF o capturas de pantalla que cargan HTML con recursos externos.
- Procesadores de ficheros (SVG, XML, documentos ofimáticos) que siguen referencias a URLs.
Cómo se busca
- Localiza cualquier campo que acepte una URL o un nombre de host.
- Pon una URL de un servidor tuyo que registre las peticiones recibidas. Si llega una petición desde la infraestructura del programa, el servidor hace peticiones salientes.
- Comprueba si llegan a destinos internos:
127.0.0.1, rangos privados o los metadatos de la nube. Respeta siempre las reglas del programa sobre qué puedes tocar. - Si hay filtros, prueba las técnicas habituales para saltarlos: redirecciones desde un servidor permitido, otras formas de escribir la IP o nombres DNS que resuelven a direcciones internas.
A veces no ves la respuesta (SSRF "ciego"). Sigue siendo un fallo, pero el impacto se demuestra con más esfuerzo, por ejemplo midiendo tiempos o con peticiones a tu propio servidor.
Cómo se evita
- Lista de destinos permitidos en lugar de lista de prohibidos.
- Resolver el nombre, comprobar que la IP no es interna y conectarse a esa misma IP (para evitar trucos de DNS), también tras cada redirección.
- Hacer las peticiones salientes desde un servicio aislado sin acceso a la red interna.
- En la nube, exigir la versión del servicio de metadatos que pide un token (por ejemplo IMDSv2 en AWS).
Al reportarlo
Muestra hasta dónde llega el servidor con pruebas que no causen daño. La gravedad depende de qué servicios internos son accesibles: un SSRF que solo llega a Internet vale mucho menos que uno que lee credenciales.
Casos reales de SSRF
Ver los 8 →SSRF en la vista previa de enlaces de Rocket.Chat: un dominio que resuelve a una IP interna esquiva el filtro
La vista previa de enlaces de Rocket.Chat 7.11.0 solo bloqueaba IPs internas escritas tal cual en la URL; un dominio apuntando a una IP privada hacía que el servidor pidiera y mostrara contenido de la red interna.
2 min
SSRF ciego por POST en phpBB: el endpoint de notificaciones Web Push aceptaba cualquier URL
En phpBB 4.0.0-alpha1, cualquier usuario registrado podía registrar una URL arbitraria como destino de sus notificaciones Web Push y obligar al servidor a enviar peticiones POST a servicios internos o a metadatos de la nube.
4 min
SSRF en Rocket.Chat: las vistas previas oEmbed seguían redirecciones hacia la red interna sin validarlas
Rocket.Chat 7.10.1 filtraba las IP internas en la URL publicada, pero no en el destino de sus redirecciones. Con un enlace acortado, el servidor pedía recursos internos y mostraba parte de la respuesta en la vista previa.
2 min
Burp MCP Server: una coma en el nombre de host convierte un clic de aprobación en varias reglas automáticas
La extensión MCP de Burp Suite guardaba el host aprobado sin validarlo. Un host con comas, aprobado con un clic, se dividía en varias entradas de la lista blanca y permitía peticiones a localhost o redes internas sin volver a preguntar.
4 min
SSRF sin autenticación en Rocket.Chat: la integración SMS de Voxtelesys burla checkUrlForSsrf con DNS rebinding
El webhook público de SMS de Voxtelesys en Rocket.Chat 7.13.2 validaba la URL de un adjunto una sola vez por DNS. Con DNS rebinding se esquivaba el filtro checkUrlForSsrf y se leían respuestas de hosts internos.
5 min
SSRF en la app Notifications de Nextcloud por un proxyServer de push controlado por el usuario
Un usuario autenticado sin privilegios podía registrar un dispositivo push indicando un servidor proxy arbitrario. Al generarse una notificación, el backend hacía una petición POST hacia esa dirección, incluidos destinos internos como localhost.
2 min