SSRF Allow-List and Filter Bypass

Once developers know SSRF exists, they add a check: block 127.0.0.1, block the metadata IP, only allow these hosts. These filters are leaky by nature, because the same destination can be spelled many ways and a hostname can change what it points to between the moment it is checked and the moment it is fetched. Bypassing them is the craft of reaching the blocked target without tripping the pattern.

How naive host checks fail

Most filters fall into a few buckets, each with a gap:

• String blocklist. Rejects literal 127.0.0.1 or localhost. Misses every alternate encoding of the same address.
• Hostname allow-list. Only permits certain hosts. Misses @ tricks and prefix or substring matches, and anything that redirects after the check.
• Resolve-then-fetch. Resolves the host, checks the IP, then fetches by name again. Misses DNS rebinding, because the second resolution can differ.

Probe first to learn which kind you face, then pick the matching bypass.

Alternate IP encodings

127.0.0.1 is just a number, and numbers have many notations. All of these reach loopback:

http://2130706433          decimal of 127.0.0.1
http://0x7f000001          hex
http://0x7f.0x0.0x0.0x1    dotted hex
http://0177.0.0.1          octal (leading zero)
http://0177.0000.0000.0001 full octal
http://127.1               short form, expands to 127.0.0.1
http://127.0.0.1.          trailing dot

The same trick re-encodes the metadata IP 169.254.169.254. A string filter that blocks the dotted-decimal form rarely blocks the decimal or octal form.

IPv6 and mixed tricks

IPv6 gives more equivalent spellings, and some stacks accept IPv4-mapped IPv6:

http://[::1]/                    IPv6 loopback
http://[::ffff:127.0.0.1]/       IPv4-mapped IPv6 for loopback
http://[0:0:0:0:0:ffff:7f00:1]/  expanded form

Case and encoding on the hostname can matter too, so try upper-case, percent-encoding, and enclosed-alphanumeric unicode digits where a parser normalizes them back to the real address.

The @ and authority tricks

A URL's authority can carry a userinfo part before an @, and the real host is what comes after it. Naive checks read the part before the @ and are fooled:

http://[email protected]/     host is 127.0.0.1, not expected-host
http://127.0.0.1#@expected-host/    fragment confuses a sloppy parser
http://expected-host.attacker.com/  prefix or contains match bypass

These work when the validator parses the URL differently from the HTTP client that eventually fetches it.

Open-redirect chaining

If the filter only allows certain hosts but the fetcher follows redirects, point it at an allowed host that you can make redirect internally:

http://trusted-host.example/redirect?to=http://169.254.169.254/

The allow-list sees trusted-host.example and passes it. The fetcher follows the 302 to the metadata IP. Any open redirect on an allowed origin becomes an SSRF filter bypass.

DNS rebinding

The strongest bypass against resolve-then-fetch filters is to make the hostname resolve to two different addresses. This is a time-of-check to time-of-use (TOCTOU) gap:

1. Your domain resolves to a public IP on the first lookup -> passes the allow-list check.
2. The TTL expires; the second lookup (the actual fetch) resolves to 127.0.0.1 or 169.254.169.254.

A rebinding service flips the A record between two addresses on a very short TTL, so the validation lookup and the fetch lookup land on different IPs. The fix is to resolve once and connect to that exact resolved IP, which is why the prevention advice is always "validate the resolved IP, not the string."

Putting it together

Bypass is a toolbox: figure out whether the filter matches strings, hostnames, or resolved IPs and whether it re-checks on redirect, then pick the cheapest trick that fits. The cheat sheet has the encodings and tricks in one place. Once you are past the filter, the highest-value destination is usually the metadata service, covered in cloud metadata abuse. Practice slipping past a filter on a free live target.