Qué es SSRF y cómo reducir sus riesgos
Autor: Redacción Domeny.ForSale Publicado
En resumen: SSRF (Server-Side Request Forgery) es una vulnerabilidad que permite a un atacante inducir al servidor de una aplicación a enviar una petición a una dirección no prevista. Así, el servidor puede acceder a recursos que no son accesibles directamente desde internet, como servicios de la red interna. A diferencia de CSRF, que utiliza el navegador del usuario, en SSRF es el propio servidor quien realiza la petición.
Cómo funciona SSRF: un ejemplo sencillo
Imagina una aplicación que permite añadir la foto de un producto pegando la dirección de una imagen. El usuario introduce una URL, es decir, la dirección del recurso, y el servidor descarga el archivo y lo guarda en el catálogo de la tienda. Es una función práctica, pero la aplicación debe comprobar adónde se conecta realmente.
Si acepta cualquier dirección, un atacante puede indicar, en lugar de una foto, un servicio accesible únicamente desde la red del servidor. La aplicación se convierte entonces en intermediaria: envía una petición a un destino al que el atacante no podría acceder por sí mismo. Si además devuelve al usuario el contenido recibido, puede revelar datos internos.
Es comparable a un recepcionista que, a petición de cualquier persona, trae documentos de salas cerradas. El problema no es traer los documentos, sino no comprobar de dónde está permitido obtenerlos y a quién se pueden entregar.
Descargar datos de una dirección proporcionada por el usuario no implica, por sí solo, que exista una vulnerabilidad. SSRF aparece cuando el usuario puede dirigir la petición fuera del ámbito permitido y la aplicación no aplica las restricciones adecuadas.
Dónde aparece SSRF y qué consecuencias puede tener
SSRF puede afectar a cualquier función que se conecte a otro recurso a partir de datos controlados por el usuario. Algunos casos habituales son la generación de vistas previas de enlaces, la importación de documentos, la descarga de imágenes y la creación de archivos PDF a partir de páginas web. Existe un riesgo similar con los webhooks, es decir, las notificaciones automáticas enviadas a una dirección indicada.
Las consecuencias dependen de los recursos a los que tenga acceso el servidor y de cómo gestione la aplicación la respuesta. Entre los posibles efectos se encuentran:
- la lectura de información de servicios internos;
- la identificación de los servicios accesibles en la red del servidor;
- el acceso a metadatos del entorno en la nube, que a veces contienen credenciales;
- la ejecución de operaciones en un servicio que confía indebidamente en el tráfico de la red interna.
SSRF no implica automáticamente que el atacante tome el control de todo el servidor. Sin embargo, el peligro aumenta cuando la aplicación tiene un acceso amplio a la red y los servicios internos no requieren autenticación.
También existe blind SSRF, o SSRF a ciegas, una variante en la que el atacante no ve directamente la respuesta del recurso solicitado. Que no se muestre el contenido no elimina la vulnerabilidad: el mero envío de la petición puede provocar una operación no deseada o revelar información a través del comportamiento de la aplicación.
SSRF y CSRF: nombres parecidos, mecanismos distintos
CSRF (Cross-Site Request Forgery) consiste en inducir al navegador del usuario a realizar una petición no deseada a una aplicación. El navegador puede adjuntar automáticamente datos de sesión, como la cookie de un usuario que haya iniciado sesión. El objetivo suele ser ejecutar una operación con los permisos de ese usuario.
En SSRF, es el servidor quien realiza la petición, y el ataque aprovecha su acceso a la red y los permisos que pueda tener. Por definición, no requiere que la víctima haya iniciado sesión, aunque la función vulnerable puede estar disponible solo tras autenticarse.
| Característica | SSRF | CSRF |
|---|---|---|
| ¿Quién envía la petición? | El servidor de la aplicación | El navegador del usuario |
| ¿Qué se aprovecha? | El acceso y los permisos del servidor | La sesión del usuario |
| Principal medida de protección | Controlar los destinos de las conexiones y el acceso a la red | Verificar las peticiones que modifican el estado, entre otras medidas mediante tokens CSRF |
Estas protecciones no son intercambiables. Un token CSRF no resuelve el problema de un servidor que descarga datos de direcciones no permitidas. A su vez, filtrar las conexiones salientes no sustituye la protección de la sesión del usuario.
Cómo reducir el riesgo de SSRF
Primero, determina si la aplicación realmente necesita descargar datos de cualquier dirección. Si la integración se limita a un servicio, es más seguro guardar su dirección en la configuración y aceptar del usuario únicamente el identificador del recurso.
Cuando sea necesario permitir que se introduzcan direcciones, aplica varias capas de protección:
- Restringe los destinos permitidos. Si la función lo permite, utiliza una lista cerrada de hosts, puertos y protocolos de confianza. No compruebes las direcciones únicamente buscando un fragmento de texto.
- Comprueba las direcciones IP de destino. Ten en cuenta tanto IPv4 como IPv6 y bloquea los rangos no permitidos, incluidas las redes privadas, las direcciones locales y los puntos de acceso especiales a los metadatos de la nube.
- Controla las redirecciones y DNS. Una dirección aparentemente segura puede redirigir a un recurso prohibido. La comprobación debe abarcar el destino real de la conexión, no solo la URL inicial.
- Limita el tráfico saliente. Las reglas de red deben impedir que la aplicación acceda a servicios que no necesita. Establece también límites de tiempo y de tamaño de las respuestas.
No reenvíes automáticamente cookies, tokens ni otras credenciales a las direcciones indicadas por el usuario. En un entorno en la nube, consulta también la documentación oficial del proveedor sobre la protección del servicio de metadatos.
Por dónde empezar a revisar la aplicación
Enumera las funciones en las que el servidor descarga datos a partir de una dirección u otro valor proporcionado por el usuario. Para cada una, determina los destinos de conexión permitidos, cómo se gestionan las redirecciones y qué datos se devuelven al usuario.
Realiza pruebas únicamente en tu propio entorno o con el permiso del propietario. Para empezar, elige una función, como la importación de imágenes, y comprueba que sus restricciones también se aplican después de una redirección, no solo a la dirección introducida en el formulario.
Consulta también: ¿Qué significa www?
Lee también
