Open Redirect | The Hack Sparrow

What it is

The app takes a URL as a parameter and redirects the user to it without validating it properly —

GET /redirect?url=https://trusted.com

becomes

GET /redirect?url=https://attacker.com

and the app happily sends the user there.

Why it matters

It looks trivial but it isn't: the link starts with a legitimate domain, which is exactly what makes it convincing for phishing, and it chains well with OAuth abuse, credential theft, and login-redirect flows.

Where to look

Parameters named

url=

redirect=

next=

return=

continue=

dest=

redirect_uri=

Endpoints like
```
/login
```
,
```
/logout
```
,
```
/sso
```
,
```
/tracking
```
,
```
/click
```

How I test it

Browse with Burp open and watch for 301/302/303/307/308 responses.
Check whether the
```
Location
```
header value comes from a controllable parameter.
Swap the destination for your own domain and confirm the redirect follows.
If blocked, try bypasses:
```
//evil.com
```
,
```
https://trusted.com@evil.com
```
(browser reads
```
trusted.com
```
as credentials,
```
evil.com
```
as the real host),
```
trusted.com.evil.com
```
, and encoding variants.
If the endpoint checks the
```
Referer
```
header, remember the browser sends it automatically when a victim clicks a link placed somewhere inside the platform itself (a bio, a comment, a public field) — the Referer check alone proves nothing.

Hunting checklist

Found a redirect-carrying parameter returning a 30x
Confirmed control over the destination
Tried
```
//evil.com
```
and
```
trusted.com@evil.com
```
variants
Tried encoding and double-encoding
Checked whether Referer validation is actually being bypassed by hosting the link inside the platform
Captured a screenshot of the browser landing on the external domain

Evidence to collect

Vulnerable URL
Vulnerable parameter
Payload used
HTTP response with the Location header
Screenshot of the browser landing on the external domain
Realistic impact — phishing, OAuth abuse, login redirect

Recommended fix

Never trust the Referer header for this
Validate with a real URL parser, compare the hostname exactly — not a substring/contains check
Strict allowlist
Reject URLs containing credentials (
```
@
```
)
Prefer internal IDs over full URLs where possible

Qué es

La app recibe una URL como parámetro y redirige al usuario sin validarla bien —

GET /redirect?url=https://trusted.com

pasa a

GET /redirect?url=https://attacker.com

y la app te manda ahí sin problema.

Por qué importa

Parece trivial pero no lo es: el enlace empieza con un dominio legítimo, que es justo lo que lo hace creíble para phishing, y encadena bien con abuso de OAuth, robo de credenciales, y flujos de redirección tras login.

Dónde buscar

Parámetros llamados

url=

redirect=

next=

return=

continue=

dest=

redirect_uri=

Endpoints como
```
/login
```
,
```
/logout
```
,
```
/sso
```
,
```
/tracking
```
,
```
/click
```

Cómo lo pruebo

Navega con Burp abierto y fíjate en respuestas 301/302/303/307/308.
Comprueba si el valor de la cabecera
```
Location
```
viene de un parámetro controlable.
Cambia el destino por tu propio dominio y confirma que la redirección sigue.
Si está bloqueado, prueba bypasses:
```
//evil.com
```
,
```
https://trusted.com@evil.com
```
(el navegador lee
```
trusted.com
```
como credenciales,
```
evil.com
```
como host real),
```
trusted.com.evil.com
```
, y variantes de encoding.
Si el endpoint comprueba la cabecera
```
Referer
```
, recuerda que el navegador la envía sola cuando la víctima hace clic en un enlace colocado dentro de la propia plataforma (una bio, un comentario, un campo público) — la comprobación de Referer sola no prueba nada.

Checklist de hunting

Encontrado un parámetro de redirección devolviendo 30x
Confirmado control sobre el destino
Probadas variantes
```
//evil.com
```
y
```
trusted.com@evil.com
```
Probado encoding y doble encoding
Comprobado si la validación de Referer se salta alojando el enlace dentro de la plataforma
Capturada la pantalla del navegador aterrizando en el dominio externo

Evidencias para el reporte

URL vulnerable
Parámetro vulnerable
Payload usado
Respuesta HTTP con la cabecera Location
Captura del navegador aterrizando en el dominio externo
Impacto realista — phishing, abuso de OAuth, redirección tras login

Mitigación

Nunca confiar en la cabecera Referer para esto
Validar con un parser real de URLs, comparar el hostname exacto — no un contains
Allowlist estricta
Rechazar URLs con credenciales (
```
@
```
)
Preferir IDs internos frente a URLs completas cuando sea posible