SSRF defence often starts with an allowlist: only fetch URLs matching specific patterns. Attackers respond with a toolkit of bypass techniques — DNS rebinding, redirect following, IP encoding tricks, and URL parser differentials — that let them reach blocked targets through the same code path.
- Explain how DNS rebinding defeats hostname-based allowlists.
- Use decimal, octal, and IPv6-mapped IPv4 representations to bypass IP filters.
- Exploit URL parser inconsistencies between the filter and the HTTP client.
- Chain redirect following to reach internal hosts from an allowed origin.
- DNS rebinding
- A technique where a domain resolves to a benign IP on the first lookup (passing the allowlist check) but to a target IP on the second lookup (when the HTTP client connects), exploiting the time window between validation and use (CWE-918).
- URL parser differential
- A discrepancy between how the allowlist validator parses a URL and how the underlying HTTP library resolves it — for example, treating userinfo as the host, or misinterpreting decimal IP notation.
- IP notation bypass
- Representing an IP address in decimal, octal, or IPv6-compatible form (e.g. 2130706433 for 127.0.0.1) to evade string-based filters that only recognise dotted-decimal notation.
The allowlist gap
A typical SSRF defence validates the target URL against an allowlist of permitted hosts before making the request. The gap between the validation step and the actual request is where bypasses live. If the validator resolves a hostname differently than the HTTP client, or if the URL is parsed differently, the check passes but the request reaches a prohibited destination.
DNS rebinding sends the validator a harmless IP on the first lookup, then switches to a malicious IP moments later when the HTTP client makes its own DNS query. Redirect following lets an allowed host forward the request to an internal endpoint. And IP representation tricks — decimal, octal, IPv6-mapped — bypass naive string-matching filters that only recognise 127.0.0.1.
Bypass the allowlist
The sandbox below simulates a URL fetcher protected by an allowlist. Try different bypass techniques — decimal IP, IPv6 mapping, redirect follow, DNS rebinding — and see which ones pass through to the internal target.
api.example.comDNS rebinding against CDN and WAF providers
In 2019, security researchers demonstrated DNS rebinding attacks against multiple major CDN and WAF providers. The attack exploited the gap between the provider's hostname validation (which allowed its own domains) and the subsequent HTTP request (which a rebinding attack redirected to an internal service). The researchers showed that any service allowing customers to supply a URL that the provider fetches is potentially vulnerable unless the provider performs the DNS resolution once and pins the IP for the request lifecycle.
Close the validation gap
The core fix is to resolve the hostname to an IP once and use that resolved IP for the connection, rejecting redirects. Validate the final IP, not the original hostname. Disable HTTP redirect following entirely unless the application has a specific need. Use a dedicated URL parser that strictly follows RFC 3986 and compare parsed components rather than doing string matching.
// VULNERABLE — string matching on hostname, redirects followed
const allowed = ['api.example.com'];
if (allowed.includes(new URL(url).hostname)) {
const resp = await fetch(url); // redirect may go anywhere
}
// SAFE — resolve IP once, reject redirects
const parsed = new URL(url);
const ip = await dnsResolve(parsed.hostname);
if (!isAllowedIP(ip)) return res.status(403).end();
const resp = await fetch(url, { redirect: 'manual' });
// SAFEST — deny private ranges by IP after resolution
function isAllowedIP(ip: string): boolean {
if (ip.startsWith('127.') || ip.startsWith('10.') ||
ip.startsWith('192.168.') || ip.startsWith('172.')) return false;
return true;
}What to remember
- Hostname-based allowlists are trivially bypassed by DNS rebinding and redirect chains.
- Resolve the IP once and pin it — never resolve the hostname twice with different results.
- Disable redirect following by default. Only enable it when the application explicitly requires it and the destination is validated at each hop.
- Decimal (2130706433), octal (0177.0.0.1), and IPv6-mapped (::ffff:127.0.0.1) IP representations bypass naive string filters.
- URL parser differentials between the validator and the HTTP client are a rich source of bypasses — use the same parser for both.
Knowledge check
0/3 answered · 0 correct1.A filter blocks "127.0.0.1" but allows "2130706433". Which technique does this represent?
2.What makes DNS rebinding effective against allowlist-based SSRF defences?
3.An application blocks all IPs matching 127.0.0.1 but does not disable redirects. How can you bypass this?