SSRF

Server-Side Request Forgery (SSRF) is a vulnerability where an attacker tricks a server into making requests to internal or external systems that the attacker cannot directly access.

General Information

We are searching for request that have:

  • Include full URLs in the POST body or parameters

  • Include full or partial URL paths in the POST body or parameters

  • Headers that include URLs, such as Referer

  • Allow for user input that may result in a server retrieving resources

To test SSRF we can use Burp's Collaborator or free alternatives, such as:

Automated tools can be use to check for SSRF, such as SSRFmap.

Examples

Typical Flaws

The below example is based on PortSwigger's SSRF module.

The /admin directory is restricted to normal users and is accessible only to administrator and if someone request it from localhost (Figure 1).

Figure 1: Trying to access administrative functionality.

The Check Stock functionality makes a call to an external resource (Figure 2).

Figure 2: Discovering a potential vulnerable-to-SSRF endpoint.

The stockApi parameter is vulnerable to SSRF and can be leverage to perform administrative operations (Figure 3).

Figure 3: Exploiting the SSRF flaw.

The below example is based on the crAPI application.

Figure 4: Identifying a potential SSRF vulnerability.
Figure 5: Validating the SSRF vulnerability.

Encoding Payloads

The below example is based on HTB's Web Service & API Attacks module.

The payload might need to be encoded for the SSRF to work (Figure 6).

# Encoding the payload
$ echo http://10.10.15.28 | tr -d '\n' | base64
aHR0cDovLzEwLjEwLjE1LjI4
Figure 6: Based64-encoding the payload to make SSRF work.

URI Paths

The below example is based on HTB's API Attacks module.

Figure 7: Leveraging SSRF & URI paths to read a local file.

Last updated

Was this helpful?