SecLab
SSRF & calling external APIswalkthroughDifficulty 3/528 min

SSRF and getting the allowlist right

Objective: After this lesson you can write an SSRF allowlist that survives DNS rebinding and redirects, and know why a blocklist always fails.

V13CWE-918API7:2023C10:2024ssrf
Step 1 of 5 · read6 min

You lend the attacker your network position

SSRF happens when your application takes a URL from a user and fetches it. What makes it serious is not the fetch but the network position it originates from: the attacker cannot reach 10.0.0.5 or 169.254.169.254, but your server can — so they borrow your reach.

Three targets, by damage in a cloud environment:

TargetWhat it yields
The metadata endpoint (169.254.169.254)The instance role's temporary credentials — everything that role can do
Unauthenticated internal servicesRedis, Elasticsearch, an admin API that is "internal so it needs no auth"
Internal network scanningA network map, from response-time differences or error codes

And now the lesson's most important part: a blocklist does not work. A list blocking 127.0.0.1, localhost, 10.*, 192.168.* looks complete and fails in at least seven different ways:

VariantExample
Decimalhttp://2130706433/ = 127.0.0.1
Octalhttp://0177.0.0.1/
Hexadecimalhttp://0x7f000001/
IPv6 and mapped formshttp://[::1]/, http://[::ffff:127.0.0.1]/
Shorthandhttp://127.1/, http://0/
DNS pointing inwardhttp://internal.attacker.tld/ → A record 10.0.0.5
RedirectA public URL returning 302 to 169.254.169.254

Those seven rows are seven cases you must remember, and the eighth is the hole. This is precisely why the fix must be an allowlist: you enumerate what is permitted, and every creative variant is simply not on it.

The last two rows deserve their own note, because they defeat even a naive allowlist:

  • DNS rebinding: you resolve the hostname, find it acceptable, then HttpClient resolves it a second time when connecting — and that time DNS returns a different IP. Check and use are two different moments.
  • Redirects: you validate the first URL, it is fine, then the server returns 302 and HttpClient follows it somewhere you never validated.
View path

Comments

Join the discussion
Sign up to comment

Commenting needs an account with at least one completed lesson. That condition is what keeps this thread worth reading: every point belongs to someone who can be asked back, and reputation accrues over time.

Sign upSign in

You can still read every comment below without an account. Signing in brings you back to this exact spot, not to the top of the page.

Loading comments…