After the last lesson the Hacker added a filter that rejects any URL containing the text localhost or 127.0.0.1. But it matches the text literally, and the same local address can be written in many forms.
The same preview tool, but the developer added a filter that bans the literal strings localhost and 127.0.0.1. One internal address has many spellings, so a text filter is easily bypassed.
Reach the internal admin panel again, bypassing the text filter.
You bypassed the text filter with an alternate form of the address and reached the internal panel.
Why the solution worked
The filter matched text, but an IP address has many equal forms (short, decimal, hex, octal), so banning one spelling does not ban the address. The right rule: resolve the address to its canonical form first, then check whether it is internal or loopback. Better still, use an allowlist of permitted destinations, so you never have to chase every possible spelling.
The root cause
The filter matches a literal address string while the OS resolves many spellings of the same address (127.1, 2130706433, 0x7f000001), so a text blacklist cannot win.
How the code is fixed
Do not check the text; check the address after resolving it to its canonical form, or better, use an allowlist.
Vulnerable code
function allowed(url) {
// String blacklist: trivially bypassed by 127.1, decimal, hex, octal...
return !/localhost|127\.0\.0\.1/.test(url);
}
Safe code
import dns from 'node:dns/promises';
async function allowed(url) {
const { address } = await dns.lookup(new URL(url).hostname); // resolve to a real IP
return isAllowlisted(new URL(url).origin) && !isPrivate(address); // check canonical IP
}
Impact in the real world
Bypassing SSRF filters with alternate address spellings is a known technique that has reached internal services despite surface-level protection.
How defenders detect it
Defenders resolve the address to its canonical form before checking, compare the actual range not the text, and block redirects to internal addresses after resolution.
