SSRF (Server-Side Request Forgery)

1. Descripción técnica del ataque

Una SSRF (Server-Side Request Forgery) ocurre cuando una aplicación web permite a un atacante manipular una petición que el servidor realiza a otro recurso.
En otras palabras, el atacante logra que el servidor actúe como proxy y realice solicitudes HTTP/HTTPS (o incluso a otros protocolos) hacia destinos que el atacante no podría acceder directamente.

Ejemplo típico en PHP:

Si el usuario accede a:

el servidor hará una petición HTTP a http://example.org y devolverá el contenido.
Pero un atacante puede manipular la URL y forzar al servidor a conectarse a recursos internos como:

Así, el atacante accede a servicios internos que normalmente están protegidos por firewalls o configuraciones de red.

2. Impacto de la vulnerabilidad

Dependiendo de cómo se use y qué protocolos estén habilitados, una SSRF puede permitir:

• Acceso a la red interna (intranet):
  Escanear puertos internos, acceder a paneles de administración o APIs internas que no son públicas.

• Acceso a metadatos en la nube:
  En AWS, por ejemplo, se puede leer: http://169.254.169.254/latest/meta-data/

  para obtener credenciales temporales de IAM, comprometiendo toda la infraestructura.

• Lectura de archivos locales (si el parser soporta file://):
  Ejemplo: ?url=file:///etc/passwd

• Exfiltración de datos sensibles:
  Si la aplicación reenvía la respuesta al atacante, puede filtrar configuraciones y credenciales.

• Movimiento lateral y pivoting:
  El servidor vulnerable se convierte en un “puente” hacia la red interna.

3. Historia y evolución

• Década de 2000s: se empezó a notar en aplicaciones con funciones de fetch o de integración con URLs externas (webhooks, parsers de imágenes, etc.).

• 2014–2016: explotaciones en entornos cloud hicieron a SSRF muy relevante, especialmente en AWS por el acceso al endpoint 169.254.169.254.

• 2017: OWASP Top 10 (A10) comenzó a considerar SSRF como una vulnerabilidad emergente.

• 2021: OWASP Top 10 lo incluye oficialmente como A10:2021 – Server-Side Request Forgery (SSRF), dado su impacto en entornos cloud modernos.

4. Factores que la hacen posible

1. Entrada controlada por el usuario usada en funciones de red como:

   • file_get_contents()
   • curl_exec()
   • URL.openConnection()
   • Integraciones con servicios de terceros (webhooks, APIs de imágenes, etc.).

2. Falta de validación o filtrado de URLs.

3. Servidor con acceso a redes internas o endpoints de metadatos en la nube.

4. Configuraciones permisivas de librerías HTTP, que permiten protocolos alternativos (file://, ftp://, gopher://, etc.).

5. Detección

• Manual:
  Intentar URLs controladas por el atacante, por ejemplo: ?url=http://127.0.0.1:22 ?url=file:///etc/passwd ?url=http://169.254.169.254/latest/meta-data/

• Automatizada:
  Herramientas como:

  • Burp Suite (Collaborator)
  • OWASP ZAP
  • SSRFire
  • Gopherus

  permiten detectar y explotar SSRF enviando payloads y verificando si el servidor interactúa con el recurso indicado.

6. Mitigación

1. Listas blancas estrictas de destinos permitidos.
   Solo permitir conexiones hacia dominios específicos y confiables.

2. Bloquear direcciones internas (ej. 127.0.0.0/8, 169.254.169.254, 10.0.0.0/8, etc.).

3. Validar y normalizar URLs de entrada (resolviendo redirecciones y verificando la IP final antes de conectarse).

4. Restringir protocolos permitidos:
   Solo HTTP/HTTPS; bloquear file://, gopher://, ftp://, etc.

5. Uso de firewalls a nivel de aplicación (WAF) que detecten patrones de SSRF.

6. En entornos cloud:
   Limitar el acceso del servidor a endpoints de metadatos o usar roles con privilegios mínimos.

7. Ejemplo de explotación real

Si una aplicación tiene:

<?php echo file_get_contents($_GET['url']); ?>

Y el atacante accede a:

http://vulnerable.site/fetch.php?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

El servidor vulnerable devolverá credenciales temporales de AWS, lo que puede llevar a compromiso total de la infraestructura cloud.

8. Clasificación

• Tipo: Server-Side Attack

• OWASP Top 10 (2021): A10 – SSRF

• CWE:

  • CWE-918 – Server-Side Request Forgery (SSRF)

9. Resumen

La vulnerabilidad SSRF permite a un atacante manipular al servidor para que realice solicitudes hacia destinos internos o externos controlados.
El impacto puede ir desde el acceso a archivos locales hasta el compromiso completo de infraestructuras cloud al acceder a endpoints de metadatos.
Hoy en día es una de las vulnerabilidades más críticas en aplicaciones que interactúan con recursos externos.