SSRF Assessment

This guide treats server-side URL fetchers, webhooks, previews, imports, and callback features as a control boundary rather than a list of attack commands. First document who owns it, who should reach it, what identity context applies, and which data or downstream systems it can affect.

• Confirmed asset owner and in-scope address or application.
• Expected clients, identities, and network zones.
• Protocol versions, encryption expectations, and authentication mode.
• Sensitive data classes and downstream dependencies.
• Monitoring owner, escalation contact, and agreed stop threshold.

1. 01

   Identify features that fetch URLs or resolve user-controlled hostnames.

2. 02

   Document schemes, ports, redirects, DNS resolution, proxying, and egress controls.

3. 03

   Prepare an organization-controlled callback endpoint containing no sensitive data.

4. 04

   Confirm cloud and internal-network testing boundaries separately.

curl -sS -X POST https://lab.example/preview \
+  -H "Content-Type: application/json" \
+  -d '{"url":"https://callback.lab.example/assessment-id"}'

A useful result demonstrates a broken security expectation with a reversible, low-impact test. Scanner labels and version matches are leads; validate the actual control and preserve the clean baseline beside the changed request.

1. 01

   Use only the approved callback endpoint to confirm server-side fetching.

2. 02

   Test normalization and redirect handling between approved public lab hosts.

3. 03

   Confirm non-HTTP schemes and disallowed ports are rejected.

4. 04

   Do not target loopback, internal services, or cloud metadata without explicit additional authorization.

ASSET / ENDPOINT:
SCOPE REFERENCE:
IDENTITY / NETWORK ZONE:
BASELINE:
CONTROL TESTED:
EXPECTED RESULT:
OBSERVED RESULT:
TIMESTAMP / REQUEST ID:
SANITIZED EVIDENCE:
STOP / CLEANUP STATUS:

• Log destination host, resolved address class, policy decision, and request correlation ID.
• Alert on private, link-local, metadata, and unusual-port destinations.
• Monitor DNS rebinding indicators and repeated policy denials.

Keep raw data only when it is necessary to reproduce the finding. Redact credentials, session values, customer content, internal addresses, and personal data before evidence enters a ticket or report.

• Use strict destination allowlists and canonical parsing.
• Resolve and validate every redirect hop.
• Block private and special-use address ranges at application and network layers.
• Require egress proxies and protect cloud metadata independently.