Una aplicación recupera del lado del servidor una URL proporcionada por el usuario (p. ej., para vistas previas de enlaces). ¿Cuál es el riesgo y la solución?
Respuesta breve
Recuperar del lado del servidor URLs controladas por el atacante es Server-Side Request Forgery (SSRF): permite alcanzar servicios internos o el endpoint de metadatos del cloud para robar credenciales. Mitíguelo con una allow-list de hosts y esquemas permitidos, bloqueando rangos privados y link-local (revisando de nuevo tras cada redirección) y endureciendo el acceso a metadatos con IMDSv2. Decir que no hay riesgo ignora el acceso que concede la petición, y un spinner de carga o una caché no cambian nada sobre dónde puede conectarse el servidor.
Cuando su servidor recupera una URL que controla un usuario — para una vista previa de enlace, un webhook, la importación de un avatar — se convierte en un «delegado confundido». El atacante no realiza la petición, pero elige dónde la realiza su servidor. Eso es Server-Side Request Forgery (SSRF), y en infraestructura cloud es una de las clases de fallo más peligrosas.
Por qué este es el riesgo real
El servidor suele situarse dentro de una red de confianza, con mucho mayor alcance que cualquier cliente externo. Al proporcionar una URL como http://169.254.169.254/latest/meta-data/, un atacante puede extraer los metadatos del cloud de la instancia — incluidas credenciales IAM temporales — y pivotar hacia su cuenta. También puede alcanzar paneles de administración internos, bases de datos y microservicios sin autenticación que asumen que «si puedes alcanzarme, eres de confianza». Así es exactamente como varias grandes brechas en el cloud escalaron desde una simple función de vista previa.
La solución correcta
Defienda en profundidad:
- Allow-list de los hosts y esquemas exactos que pretende recuperar (solo
https, solo dominios conocidos). Una allow-list falla en cerrado; una deny-list de rangos «malos» siempre deja escapar algo. - Resuelva usted mismo el nombre de host y bloquee los rangos privados, de loopback y link-local (
127.0.0.0/8,10/8,192.168/16,169.254/16, equivalentes IPv6) — y revise de nuevo tras cada redirección, porque un host permitido puede devolverle un 302 hacia169.254.169.254. - Endurezca los metadatos con IMDSv2, que exige un token de sesión firmado mediante una petición PUT, anulando el simple GET que puede realizar un SSRF.
Por qué las demás respuestas son incorrectas
«Sin riesgo — es solo una petición HTTP» es precisamente la mentalidad que despliega SSRF; el peligro está en la posición de red, no en el protocolo. Un spinner de carga es un detalle de UX. Cachear la respuesta incluso puede empeorar las cosas al almacenar datos internos. Ninguna de esas opciones restringe dónde se conecta el servidor, que es todo el problema que el entrevistador busca sondear.
Posibles preguntas de seguimiento
- ¿Cómo se evita el SSRF mediante DNS rebinding o una redirección HTTP a 169.254.169.254?
- ¿Por qué una allow-list de hosts es más segura que una deny-list de rangos privados?
- ¿Qué cambia IMDSv2 respecto a cómo se puede alcanzar el endpoint de metadatos?