search

Examples

hashtag
Localhost SSRF

The example below is based on PostSwigger's Basic SSRF against the local serverarrow-up-right 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.

hashtag
Local Network SSRF

The example below is based on PostSwigger's Basic SSRF against another back-end systemarrow-up-right 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 Intruderarrow-up-right extension (Figure 7).

Figure 7: Performing a BFA with Turbo Intruder.

hashtag
Blind SSRF

circle-info

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.

hashtag
Out-Of-Band

The example below is based on PostSwigger's Blind SSRF with out-of-band detectionarrow-up-right 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 alternativesarrow-up-right.

Figure 9: Validating a blind SSRF vulnerability.

hashtag
Shellshock

The example below is based on PostSwigger's Blind SSRF with Shellshock exploitationarrow-up-right 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 herearrow-up-right as well as guidance on how to use Burp's Collaborator Everywhere extension to exploit it herearrow-up-right (Figure 11).

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

hashtag
Web Server Logs

The example below is based on OffSec's WEB-200arrow-up-right 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.

hashtag
Gopher

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

Some user agents, such as curl, support the Gopherarrow-up-right 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).

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 CyberChefarrow-up-right to double URL-encode the payload (Figure 16), then manually URL-encode the & character, and pass it to the SSRF vulnerable application (Figure 17).

Figure 16: Double URL-encoding the payload.
Figure 17: Leveraging the gopher protocol via a SSRF vulnerability.
PreviousExploitationNextWAFs

Last updated