Introduction to server-side request forgery

Server-side request forgery, also known as SSRF is the process of altering certain requests from a webserver to internal resticted systems. This type of attack is typically used to retrieve sensitive and restricted content.

Still confussed? That's fine, let me give an example. Say we have an online shop, this shop has a website with a stock check feature. When a user checks to see if the website has an item in stock it sends a request to a stock management system, this system is located on the local network. Although the user cannot directly access the stock management system as it is not connected to the wider internet they are able to make requests through the website, as the request is coming from a local trusted source (the website) it will happily respond.

I'm sure that you're now seeing where this is going, if the requests are visable to the user then they'll potentially be able to alter the request and retrieve content which sould not be accessible.

A simple example of SSRF

POST /item/computer 200 HTTP/1.1
Host: vulnerable.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:104.0) Gecko/20100101 Firefox/104.0
Server: Apache
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded

request=http://198.162.0.32:5050/check%253Fid%253D21%2526location%253DRosyth

In the example above we have a POST request, whats interesting here is the data which is being sent. As you can see there is a local ip address, meaning that this location would not be accessible to the Internet directly but as the request is coming from a webserver on the same network the connection would be accepted and would return the stock count.

So how might an attacker exploit this? To make this simple lets say we already know what the system layout is like and where a configuration file might be located, this means we're able to retrieve a configuration file.

POST /item/computer 200 HTTP/1.1
Host: vulnerable.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:104.0) Gecko/20100101 Firefox/104.0
Server: Apache
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded

request=http://198.162.0.32:5050/config/settings.json

Rather than returning a stock count, as the request is coming from a trusted source it would return the settings.json contents.

Although the example given is rather basic, this type of attack could potentially expose many sensitive systems to attackers, these systems could include but would not be limited to administration panels.

Protecting against SSRF

Server-side request forgery occurs when the web application does not have correct controls in place to specify what what access should be granted. Lets take the example we gave earlier, one method we may be able to use would be use regular expressions to validate the requested URL is allowed. I have provided a simple PHP example below, if the URL is not an exact match then it will not proceed and the request will not be made.

Please note, raw input should always be sanitized before it is sent to any webserver. This can be done in PHP with functions such as htmlentities() or htmlspecialchars(). Additonal functions are available for database sanitization.

if(preg_match('/^https:\/\/192\.168\.0\.32:5050\/check\?id=([0-9].*)&location=([a-zA-Z].*)$/', $_POST['request']))
{
    //make request...
}

So what happens if the web application speaks with multiple restricted systems? Well, in situations like this we can make use of a whitelist. A whitelist is essentially a list of pre-approved domains or ip addresses, if the request is not specified as okay then the web page will prevent any information from being sent.

Still need help?

Are you having trouble using arctil? Why not try reaching out to our Community Forum.

Alternatively, you can try contacting us through the Contact page.