Learn Hacking by Actually Hacking

Difficulty

Intermediate

Vuln class

Server-Side Request Forgery (SSRF)

Steps

// Objective

Abuse the link preview feature to make the server send requests to internal infrastructure and retrieve the flag from an internal config endpoint.

// Tools required

BrowserBurp Suite

// Step-by-step walkthrough

Understand how link preview works

When you paste a URL into WhatsUp, the server fetches that URL to generate a preview (title, description, image). That fetch happens server-side — meaning it originates from within the server's network, not your browser.

Test for SSRF with localhost

Instead of a public URL, try pointing the preview at localhost. If the server fetches it and returns the response, you have SSRF.

Command / Input

Paste URL: http://localhost

Output

Preview shows the server's own index page — confirms SSRF.

⚑ The server is now fetching its own pages on your behalf. This means you can reach internal services not exposed to the internet.

Probe internal network ranges

Cloud environments typically have a metadata endpoint at 169.254.169.254. Internal services often run on ports like 8080, 8888, 9000. Start probing.

Command / Input

http://169.254.169.254/latest/meta-data/ http://localhost:8080/ http://127.0.0.1:9000/config

Hit the internal config endpoint

The flag is stored in an internal configuration service running on the server that isn't accessible from the internet.

Command / Input

http://localhost:8888/internal/config

Output

{"env":"production","flag":"HackrGG{ssrf_r34ch3d_1nt3rn4l_c0nf1g}","db_host":"db.internal"}

⚑ In real SSRF attacks this endpoint often contains cloud credentials, internal API tokens, and database connection strings.

// Flag

Flag value

HackrGG{ssrf_r34ch3d_1nt3rn4l_c0nf1g}

Retrieved from an internal config endpoint only reachable via SSRF.

Link Preview — WhatsUp