This is a series of Security related articles I wrote. This article is the first one.
Introduction
In computer security, Server-Side Request Forgery (SSRF) is a type of exploit where an attacker abuses the functionality of a server causing it to access or manipulate information in the realm of that server that would otherwise not be directly accessible to the attacker.[wiki]
Similar to cross-site request forgery which utilizes a web client, for example, a web browser, within the domain as a proxy for attacks; an SSRF attack utilizes an insecure server within the domain as a proxy.
This is the structure of this article,
- Introduction
- A - What is Server-Side Request Forgery (SSRF)
- B - Typical exploitation of a SSRF Vulnerability via a Web Server
- C - Typical Way to Introduce a SSRF Vulnerability
- D - Impacts of a SSRF Vulnerability
- E - Circumventing common SSRF defenses
- F - An Example
A - What is Server-Side Request Forgery
I like this definition:
In a Server-Side Request Forgery (SSRF) attack, the attacker can access a server and abuse functionality on the server to read or update internal resources.
The points are that attacher can
- Access the Server;
- Abuse functionality on the Server.
B - Typical exploitation of a SSRF Vulnerability via a Web Server
Due to the protection of system firewall, an external attacker can’t use direct requests, instead, they make their attack via a vulnerable web server.
In a typical SSRF scenario, an external attacker who wants to access an internal server can’t use direct requests because they would be blocked by the firewall. Instead, malicious actors can exploit an SSRF vulnerability to make their attack via a vulnerable web server:
![]()
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, they may be able to force the server to connect to arbitrary external systems, potentially leaking sensitive data such as authorization credentials.
![]()
C - Typical Way to Introduce a SSRF Vulnerability
An SSRF vulnerability is introduced when user-controllable data is used to build the target URL. To perform an SSRF attack, an attacker can then change a parameter value in the vulnerable web application to create or control requests from the vulnerable server.
External resources accessed by a web application may include internal services, for example an RSS feed from another website. A developer might use the following URL to retrieve a remote feed:
https://example.com/feed.php?url=externalsite.com/feed/to
If the attacker is able to change the url parameter to localhost (the loopback interface), this may allow them to view local resources hosted on the server, making it vulnerable to server-side request forgery.
D - Impacts of a SSRF Vulnerability
If attackers can control the destination of server-side requests, this opens up a whole array of offensive activities, potentially allowing them to:
- Abuse the trust relationship between the vulnerable server and other systems
- Bypass IP whitelisting
- Bypass host-based authentication services
- Read web resources and other useful assets that are not accessible to the public, for instance metadata APIs in AWS environments or
trace.axd in ASP.NET
- Perform port scans on the internal network that the server is connected to
- Read files from the web server
- View status pages and interact with APIs as the web server
- Retrieve sensitive information such as the IP address of a web server running behind a reverse proxy
E - Circumventing common SSRF defenses
It is common to see applications containing SSRF behavior together with defenses aimed at preventing malicious exploitation. Often, these defenses can be circumvented.
E - 1: SSRF with blacklist-based input filters
Some applications block input containing hostnames like 127.0.0.1 and localhost, or sensitive URLs like /admin.
E - 2: SSRF with whitelist-based input filters
Some applications only allow input that matches, begins with, or contains, a whitelist of permitted values. In this situation, you can sometimes circumvent the filter by exploiting inconsistencies in URL parsing.
E - 3: Bypassing SSRF filters via open redirection
It is sometimes possible to circumvent any kind of filter-based defenses by exploiting an open redirection vulnerability.
Reference