Intro to SSRF (Server-Side Request Forgery)

Overview

SSRF (Server-Side Request Forgery) is a vulnerability where an attacker can make the server perform HTTP requests to targets the attacker chooses. That can mean hitting internal services, cloud metadata endpoints, or exfiltrating data — and blind SSRF still matters because you can detect it out-of-band.

1) What SSRF is

Definition: forcing the web server to make an additional or modified request to a resource of the attacker’s choosing.

• Regular SSRF: server response comes back to you.
• Blind SSRF: server makes the request, but you don’t see the response.

2) Impact (why it’s nasty)

• Access to unauthorized internal areas/services
• Access to customer/org data
• Pivot/scale into internal networks
• Leak auth tokens/credentials (esp. cloud metadata)

3) Where to look (common SSRF entry points)

SSRF usually shows up anywhere the app “fetches” something for you:

• Full URL param: ?url=https://example.com/image.png
• Hidden form fields that store a URL/path the server will request
• Partial URL (hostname only): srv=filestorage.cloud.thm&port=8001
• Path only (server prepends host): ?path=/avatar/1.png

4) Defeating common SSRF defenses

Deny list (blocklist)

Deny lists block “bad” hosts like localhost, 127.0.0.1, or metadata IPs. Bypasses often use alternate representations.

• Alternate localhost forms: 127.1, 0, 0.0.0.0, 2130706433, etc.
• DNS tricks: use a domain that resolves to 127.0.0.1 (e.g. 127.0.0.1.nip.io)
• Cloud metadata often at 169.254.169.254 (also bypassable via DNS tricks)

Allow list

Allow lists only allow URLs that match a pattern like https://website.thm. A classic bypass is a subdomain trick:

https://website.thm.attacker-domain.thm

Open redirect chaining

If the app only allows URLs starting with the target domain, an open redirect endpoint on that domain can bounce the server-side request to your real target.

5) Practical pattern (TryHackMe lab)

TryHackMe’s scenario uses an avatar selection feature where the server fetches a resource based on a form value.

• Find the avatar field value in page source / DevTools
• Change it to a restricted internal path (e.g. /private)
• If denied, bypass with traversal-like normalization

# bypass example from the room
avatar = x/../private

Because ../ normalizes paths, x/../private becomes /private server-side and can bypass naive “starts with /private” checks.

Exam Notes (PT1) — SSRF checklist

• Hunt for any feature that “fetches” a URL/path (avatars, PDFs, import-by-URL, webhooks, previews).
• Decide if it’s regular vs blind SSRF; if blind, set up out-of-band logging.
• Test internal targets (localhost/internal hostnames), and cloud metadata (169.254.169.254).
• If blocked: try alternate host representations, DNS-resolving tricks, allowlist bypass via subdomains, and open redirect chaining.
• Watch for normalization tricks like x/../ when simple prefix checks exist.