Introduction to server-side request forgery and common attacks, SSRF series (Part 1a)

Vipul Jain

6 min readAug 5, 2024

Introduction

Server-side request forgery is a web security vulnerability that allows an attacker to cause the server-side application to make requests to an unintended location.
In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization’s infrastructure.
In other cases, the attacker may be able to force the server to connect to arbitrary external systems.
This could leak sensitive data, such as authorization credentials.

Impact of SSRF attacks

A successful SSRF attack can often result in unauthorized actions or access to data within the organization.
This can be in the vulnerable application, or on other back-end systems that the application can communicate with.
In some situations, the SSRF vulnerability might allow an attacker to perform arbitrary command execution.
An SSRF exploit that causes connections to external third-party systems might result in malicious onward attacks, these can appear to originate from the organization hosting the vulnerable application.

Common SSRF attacks

SSRF attacks often exploit trust relationships to escalate an attack from the vulnerable application and perform unauthorized actions.
These trust relationships might exist in relation to the server, or in relation to other back-end systems within the same organization.

Imagine a network with multiple systems:

A web application (the vulnerable application) is accessible from the internet.
Behind the scenes, this web application might interact with other systems within the organization’s network, such as databases, internal APIs, or other services.

Types of Trust Relationships:

1.Trust Between Web Application and Server:

The web application might be designed to fetch data from internal databases or APIs.
This implies a trust relationship where the server hosting the web application trusts the requests it receives from the application itself.
In an SSRF attack, the attacker exploits this trust by tricking the application into making unintended requests to unauthorized locations.

2.Trust Between Servers:

Different servers within the network might have established trust relationships to enable them to communicate and exchange data.
An attacker could exploit a vulnerability in one server to forge a request that appears to come from another trusted server. This forged request might trick the target server into performing unauthorized actions.

Exploiting trust for malicious gain:

Normally, these trust relationships allow legitimate communication and data exchange within the network.
An SSRF attack disrupts this by manipulating the trusted communication channels for malicious purposes.

Examples:

Example 1 (Web App and Server): The web application might trust user input for searching a product catalog. The attacker injects a URL pointing to an internal database instead of a product name. The server, trusting the application’s request, retrieves data from the unauthorized database.
Example 2 (Server to Server): A server responsible for managing user accounts trusts requests from another server that handles order processing. The attacker exploits a vulnerability in the order processing server to forge a request that appears to come from the trusted server. This forged request might trick the user account management server into granting unauthorized access.

In essence, SSRF attacks take advantage of existing trust relationships between systems to bypass security restrictions and gain unauthorized access to data or functionalities.

SSRF attacks against the server

In an SSRF attack against the server, the attacker causes the application to make an HTTP request back to the server that is hosting the application, via its loop-back network interface.
This typically involves supplying a URL with a host-name like 127.0.0.1 (a reserved IP address that points to the loop-back adapter) or localhost (a commonly used name for the same adapter).
The URL is supplied so as to access the resources on a server or a system that is outside of the application itself.
Consider a shopping application that lets the user view whether an item is in stock in a particular store.
To provide the stock information, the application must query various back-end REST APIs. It does this by passing the URL to the relevant back-end API endpoint via a front-end HTTP request.
When a user views the stock status for an item, their browser makes the following request:

POST /product/stock HTTP/1.0 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 118 

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

This causes the server to make a request to the specified URL, retrieve the stock status, and return this to the user.

Exploiting the vulnerability

In this example, an attacker can modify the request to specify a URL local to the server:

POST /product/stock HTTP/1.0 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 118 

stockApi=http://localhost/admin

The server fetches the contents of the /admin URL and returns it to the user.
An attacker can visit the /admin URL, but the administrative functionality is normally only accessible to authenticated users.
Thus it might be the case that attacker won’t see anything of interest. However, since the request to the /admin URL comes from the local machine, the normal access controls are bypassed.
The application grants full access to the administrative functionality, because the request appears to originate from a trusted location that is the application itself which the server trusts.

Potential reasons for implicitly trusting the request

The access control check might be implemented in a different component that sits in front of the application server. When a connection is made back to the server, the check is bypassed.
For disaster recovery purposes, the application might allow administrative access without logging in, to any user coming from the local machine. This provides a way for an administrator to recover the system if they lose their credentials. This assumes that only a fully trusted user would come directly from the server.
The administrative interface might listen on a different port number to the main application, and might not be reachable directly by users. This is a security best practice as it separates user traffic from administrative functionalities. Thus the server trusts that a request to admin account is not possible from the main application itself thus ignoring the port number and trusting the request from the application.

These kind of trust relationships, where requests originating from the local machine are handled differently than ordinary requests, often make SSRF into a critical vulnerability.

Now consider this lab from Web Security Academy.

Lab: Basic SSRF against the local server

Lab Description

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.

Lab Solution

To access the "check stock" feature we click on any of the products as in the screenshot below.

Now check for this captured request in burp suite.

Now send the request to repeater.

Now change the URL of the stockApi to the one given in the lab description as shown in the screenshot below. This modification sends the request back to the server, to a location that is local to the server which is hosting the application.

Finally send this request and the response for the same is as shown in the screenshot below.

Now look for the path that will delete user Carlos and replace the stockApi URL with that as shown in the images below.

Finally send this request and as can be seen below the user has been deleted successfully and lab has been solved.

In the next part of this series I will explain about SSRF attacks against other back-end systems. Further I will solve lab from Web Security Academy based on this concept.