Examples

Localhost SSRF

The example below is based on PostSwigger's Basic SSRF against the local server lab.

The Check Stock feature makes a call to an internal API endpoint and fetches back the product availability, but it appears to be limited to reaching only local resources (Figure 1).

Figure 1: Identifying a potential SSRF vulnerability.

If we try to access the /admin directory externally, the application let us know that it can only be accessed by the administrator account or the localhost, i.e., internally (Figure 2).

Figure 2: Trying to access the /admin directory externally.

Thus, we can access the admin panel via the stockApi parameter and use the information provided to delete user carlos (Figure 3).

Figure 3: Deleting user carlos by accessing admin functionality.

Local Network SSRF

The example below is based on PostSwigger's Basic SSRF against another back-end system lab.

When a user uses the Check Stock feature the application sends a requests to another system within its internal network (Figure 4).

Figure 4: Understanding how stock is checked.

Since the above request reaches the internal network (192.168.0.0/24), we can check if there are any other hosts available using Intruder (Figure 5).

Figure 5: Fuzzing the internal network for live hosts.

The host 192.168.0.78 is alive, thus, we can try accessing the admin interface through it (Figure 6).

Figure 6: Leveraging the newly-discovered live host to access the admin functionality.

The above attack can be also be done with Burp's Turbo Intruder extension (Figure 7).

Figure 7: Performing a BFA with Turbo Intruder.

Blind SSRF

Blind SSRF occurs when the attacker cannot see the response from the server's request. Instead, they exploit the server to make requests and infer information based on the behavior of the server or the responses it triggers, such as changes in the application's behavior or error messages.

Out-Of-Band

The example below is based on PostSwigger's Blind SSRF with out-of-band detection lab.

When browing through the app's products, we notice the the Referer header has a URL as its value. This could be potentially be vulnerable to an SSRF attack (Figure 8).

Figure 8: Identifying a potential Blind SSRF vulnerability.

We can test if a Blind SSRF vulnerability is present using Burp's Collaborator (Figure 9) or any of the free alternatives.

Figure 9: Validating a blind SSRF vulnerability.

Shellshock

The example below is based on PostSwigger's Blind SSRF with Shellshock exploitation lab.

Burp's active scan combined with the Collaborator Everywhere extension identifies an SSRF vulnerability via the Referer header which exposes the User-Agent header (Figure 10).

Figure 10: Identifying an SSRF vulnerability which exposes the User-Agent header.

Information about the Shellshock vulnerability can be found here as well as guidance on how to use Burp's Collaborator Everywhere extension to exploit it here (Figure 11).

Figure 11: Fuzzing the internal network & revealing the hostname.

Web Server Logs

The example below is based on OffSec's WEB-200 course.

If we find a potential vulnerable to SSRF input field, we can start a local web server, such as Apache2, send a request to it (Figure 12), and then inspect its logs which may reveal useful information.

Figure 12: Testing for SSRF.

$ cat /var/log/apache2/access.log | grep ssrf
192.168.239.101 - - [17/Aug/2024:08:04:01 +0100] "GET /ssrf HTTP/1.1" 404 493 "-" "python-requests/2.26.0"
192.168.239.101 - - [17/Aug/2024:08:04:51 +0100] "HEAD /ssrf HTTP/1.1" 404 140 "-" "curl/7.79.1"
192.168.239.101 - - [17/Aug/2024:08:05:38 +0100] "HEAD /ssrf HTTP/1.1" 404 196 "-" "Wget/1.21.1"

Gopher

The example below is based on OffSec's WEB-200 course.

Some user agents, such as curl, support the Gopher protocol, which can be used to bypass some of the restrictions of a traditional SSRF flaw. Gopher allows newline characters in URLs which can be used to inject headers on the request. We should keep in mind that the first character of a Gopher request gets truncated (Figure 13).

GET /gopher HTTP/1.1
Host: 127.0.0.1:9000
User-Agent: curl/7.74.0
Accept: */*

Figure 13: The first character of a Gopher's payload get's truncated.

We can leverage the Gopher protocol to mimic a normal HTTP request and play around with different HTTP methods. Gopher normally runs on port 70, so we need to make sure that we include the appropriate port (Figure 14 & 15).

Figure 14: Mimicking a GET HTTP request via Gopher.

Figure 15: Sending a HTTP POST request with Gopher via a SSRF vulnerability.

If we want to mimic a POST request the relevant headers and parameters should be injected as well.

When data is submitted via a browser using an HTML form with the POST method, the Content-Type header will have a default value based on the form's enctype attribute. If the latter is not specified:

1. It will default to application/x-www-form-urlencoded .

2. If the form contains file upload fields (<input type="file">), the browser will automatically set the enctype to multipart/form-data.

3. If the form’s enctype="text/plain" is explicitly set, the data will be sent as plain text without any encoding.

For example, if the following POST request needs to be passed via gopher, we can use CyberChef to double URL-encode the payload (Figure 16), then manually URL-encode the & character, and pass it to the SSRF vulnerable application (Figure 17).

gopher://127.0.0.1:80/_POST /api/admin/create HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Content-Length: 31

username=admin3&password=admin3

Figure 16: Double URL-encoding the payload.

# final payload used
gopher://127.0.0.1:80/_POST%2520/api/admin/create%2520HTTP/1.1%250D%250AContent-Type:%2520application/x-www-form-urlencoded;charset=UTF-8%250D%250AContent-Length:%252031%250D%250A%250D%250Ausername=admin3%26password=admin3

Figure 17: Leveraging the gopher protocol via a SSRF vulnerability.