Tema 12
Cuando una aplicación permite que el atacante influya en qué recursos solicita el servidor, deja de ser el navegador del usuario quien hace la petición y pasa a ser la propia infraestructura del sistema. Eso cambia completamente el impacto: el atacante puede aprovechar la posición, privilegios y confianza del servidor para alcanzar destinos internos o sensibles que no estaban pensados para él.
Muchas aplicaciones web necesitan hacer solicitudes desde el servidor hacia otros recursos. Por ejemplo, pueden descargar imágenes, consultar APIs externas, validar webhooks, generar vistas previas de URLs, conectarse con servicios internos o consumir metadatos de otros sistemas. Estas funciones son legítimas, pero pueden volverse peligrosas si el atacante logra controlar parcial o totalmente el destino de la solicitud.
Eso es precisamente lo que ocurre en SSRF, Server-Side Request Forgery. El atacante no envía la solicitud directamente al recurso objetivo; convence a la aplicación para que sea ella quien la realice. Así aprovecha la posición privilegiada del servidor dentro de la red, sus permisos y su acceso a recursos que normalmente no estarían expuestos al exterior.
Esta categoría ganó importancia porque las arquitecturas modernas usan muchos servicios internos, metadata endpoints, APIs privadas y entornos cloud donde el servidor de aplicación tiene visibilidad privilegiada sobre recursos altamente sensibles.
Existe SSRF cuando la aplicación permite que un atacante influya en la URL, host, protocolo o destino de una solicitud que será realizada desde el lado servidor sin restricciones suficientes.
La secuencia conceptual suele ser esta:
La gravedad de SSRF proviene del contexto privilegiado desde el cual sale la solicitud. El servidor puede tener acceso a destinos internos que el atacante externo no puede alcanzar directamente.
Eso puede habilitar:
SSRF no aparece solo en herramientas extrañas. Puede surgir en funcionalidades bastante comunes.
Cuanto más flexible sea la capacidad de definir destinos, mayor es el riesgo si no existen restricciones fuertes.
Uno de los objetivos más habituales del atacante es usar el servidor para alcanzar destinos internos que desde internet no están expuestos. Esto puede incluir servicios en localhost, redes privadas, puertos de administración, herramientas internas o APIs pensadas solo para comunicación entre componentes confiables.
La aplicación actúa entonces como un proxy involuntario hacia la red interna.
En entornos cloud, SSRF puede ser especialmente crítica porque muchas plataformas exponen servicios de metadata accesibles desde la instancia o contenedor. Estos endpoints suelen ofrecer información sensible sobre la identidad de la máquina, tokens temporales, configuración o contexto del entorno.
Si el atacante logra que el servidor consulte esos endpoints, puede obtener información muy valiosa para ampliar el compromiso o moverse hacia otros recursos del entorno cloud.
| Objetivo | Impacto posible |
|---|---|
| Consultar servicios internos | Descubrir o abusar de endpoints no expuestos públicamente |
| Leer metadata cloud | Obtener tokens, identidad de instancia o detalles sensibles |
| Escanear puertos internos | Mapear superficie de ataque dentro de la red |
| Acceder a servicios administrativos | Cambiar configuraciones o abusar de herramientas internas |
| Encadenar con otras fallas | Pivoting, exfiltración o movimiento lateral |
No siempre el atacante recibe el contenido completo de la respuesta. En algunos casos, la aplicación devuelve directamente el resultado de la solicitud forzada. En otros, el atacante solo puede inferir si la solicitud funcionó observando tiempos, diferencias de respuesta o efectos laterales. A esto último se lo suele llamar SSRF ciega.
La SSRF ciega sigue siendo peligrosa porque puede servir para escanear, detectar servicios o activar acciones internas aunque el contenido no se devuelva al cliente.
Muchas defensas débiles contra SSRF intentan bloquear ciertos patrones de texto, dominios o cadenas concretas. El problema es que los destinos pueden representarse de múltiples formas y la validación superficial suele ser insuficiente.
El enfoque robusto no debería ser "bloquear algunas URLs peligrosas", sino controlar fuertemente qué destinos son válidos y qué tipos de solicitud necesita realmente la funcionalidad.
Incluso si la aplicación valida inicialmente un dominio permitido, puede seguir una redirección hacia otro destino no previsto si no controla bien ese comportamiento. Esto abre una vía adicional para que el atacante termine alcanzando recursos internos o sensibles sin haberlos declarado de forma directa al principio.
Por eso la validación debe considerar también el flujo completo de la solicitud y no solo la URL inicial.
El riesgo no se limita a HTTP o HTTPS. Según la implementación, una funcionalidad insegura puede aceptar distintos esquemas o protocolos, ampliando la superficie de abuso. Desde seguridad, la pregunta no es solo "qué dominio se consulta", sino también "qué tipo de recurso y mediante qué mecanismo".
Cuanta más flexibilidad innecesaria tenga el cliente del lado servidor, mayor será la complejidad defensiva.
SSRF es especialmente desafiante porque muchas aplicaciones sí necesitan hacer solicitudes externas legítimas. Por ejemplo, integraciones, fetch de contenidos, procesadores de documentos o verificaciones de servicios. En estos casos, la defensa no consiste en "prohibir toda salida", sino en diseñar la funcionalidad con restricciones y segmentación adecuadas.
Buenas preguntas de diseño:
La primera línea de defensa está en reducir y validar fuertemente el destino permitido.
La defensa contra SSRF no debería depender solo de validaciones de aplicación. La infraestructura puede reducir mucho el impacto mediante segmentación y control de egreso.
En entornos cloud, las consecuencias de SSRF suelen ser mayores porque el servidor puede tener acceso a identidad de instancia, secretos temporales, servicios internos y APIs administrativas. Esto vuelve indispensable revisar la arquitectura con mentalidad de mínimo privilegio y segmentación.
Una SSRF grave en cloud no siempre termina en lectura de una página interna. Puede abrir la puerta a credenciales temporales, inventario del entorno o movimiento lateral hacia otros servicios.
SSRF a menudo no actúa sola. Puede combinarse con otras debilidades para producir compromisos más amplios.
Esto explica por qué SSRF puede escalar rápidamente desde una simple URL controlada por el usuario hasta un compromiso de infraestructura.
Server-Side Request Forgery demuestra que una simple funcionalidad de acceso remoto puede transformarse en una vía de pivote extremadamente poderosa cuando el servidor confía demasiado en destinos controlados por el usuario. El problema no es solo una URL mal validada: es permitir que el atacante utilice la posición de la aplicación dentro de la red como herramienta propia.
Con este tema completamos las diez categorías del OWASP Top 10 2021. En los próximos temas del curso profundizaremos en vulnerabilidades web complementarias como XSS, CSRF, carga de archivos, APIs inseguras, pruebas de seguridad y estrategias prácticas de defensa en profundidad.