SSRF
Server-Side Request Forgery (SSRF) is a web security vulnerability that allows an attacker to manipulate a server into making unauthorized requests to unintended destinations. In a typical SSRF attack, the attacker might force the server to communicate with internal-only services within the organization's infrastructure. In more severe cases, the attacker can redirect the server to external systems, potentially leaking sensitive information such as authorization credentials.
Impact of SSRF Attacks
A successful SSRF attack can lead to unauthorized access, data breaches, and even remote command execution in some scenarios. The impact can be categorized into two main areas:
Access to Internal Systems – The attacker can exploit SSRF to access internal databases, APIs, or cloud metadata services, which are not normally accessible from outside the network.
External Exploitation – The vulnerability may allow an attacker to use the compromised server as a proxy for further attacks on third-party systems. This can lead to reputational damage as the attack appears to originate from the victim organization.
In extreme cases, SSRF can be leveraged to execute arbitrary commands, leading to full system compromise.
Common SSRF Attacks
SSRF attacks often exploit trust relationships between servers to escalate privileges and perform unauthorized actions. These trust relationships may exist in different layers of the organization’s infrastructure.
Understanding Trust Relationships in SSRF
Organizations typically have networks where different systems communicate with each other:
The Web Application – The front-end system accessible to users.
Internal Services – Databases, internal APIs, and back-end services that interact with the web application.
Other Trusted Servers – Servers that communicate within the organization's infrastructure.
By exploiting trust relationships, attackers can manipulate these systems to gain unauthorized access.
Types of Trust Relationships in SSRF Attacks
1. Trust Between a Web Application and Its Server
Many web applications retrieve data from internal databases or APIs based on user input.
The server trusts the requests from the application, assuming they are legitimate.
An attacker can exploit this trust by injecting a malicious URL, causing the application to fetch sensitive data from an unauthorized source.
Example: A vulnerable e-commerce website allows users to search for products. Instead of entering a product name, an attacker inputs a URL pointing to an internal database. Since the server trusts the application, it processes the request and exposes sensitive internal data.
2. Trust Between Internal Servers
Different servers in a network often trust each other to enable seamless communication.
If one server is compromised, an attacker can forge a request that appears to come from a trusted server.
This can trick the target server into performing unauthorized actions, such as accessing restricted user accounts or modifying critical system configurations.
Example: A company’s user account management system trusts requests from an order-processing server. An attacker exploits a vulnerability in the order-processing server and sends a forged request that appears to originate from the trusted server. As a result, the attacker gains unauthorized access to user accounts.
Exploiting Trust for Malicious Gain
Trust relationships are designed to facilitate secure communication and data exchange within an organization. However, SSRF exploits these relationships to bypass security controls and gain unauthorized access.
By understanding how SSRF attacks work and how trust relationships can be abused, organizations can take proactive measures to secure their applications, such as implementing strict request validation, using allowlists, and restricting internal server access.
1- SSRF Attacks Against the Server
In an SSRF attack against the server, an attacker manipulates the application into making an HTTP request to itself via the loopback network interface. This is typically done using reserved IP addresses like 127.0.0.1 or the hostname localhost, both of which refer to the local machine.
The goal of this attack is to exploit trust relationships within the application, gaining access to internal resources that should not be directly accessible to users.
Example: Exploiting SSRF in a Shopping Application
A shopping app fetches stock info from an internal API:
The server processes this request by fetching data from the specified stockApi URL and returning the stock status to the user.
but an attacker can modify the request to target a local resource on the server, such as an administrative interface:
Since the request originates from the server itself, the application may grant access to /admin, exposing sensitive administrative functionalities.
Why Does This Exploit Work?
Under normal circumstances, an attacker visiting /admin directly would be denied access due to authentication checks. However, because the request in this SSRF attack originates from the local machine, these access controls may be bypassed. This happens because the application mistakenly trusts requests coming from itself.
Potential Reasons for Implicit Trust
Access Control is Implemented at the Perimeter:
Some applications use external security layers (e.g., firewalls, reverse proxies) to enforce authentication before traffic reaches the main server.
When the request is made internally, it bypasses these security controls.
Emergency Access for Disaster Recovery:
Some applications allow administrative access from the local machine without authentication, assuming only trusted users will access it.
This feature is intended for system recovery but creates an SSRF risk if exploited.
Administrative Interface on a Different Port:
Best practices recommend hosting administrative interfaces on non-standard ports to separate them from regular user traffic.
However, the application may trust any request originating from itself, ignoring the port number, and granting unintended access.
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.
2- SSRF attacks against other back-end systems
In many applications, the server can communicate with internal back-end systems that are not directly accessible by users. These systems often have non-routable private IP addresses and are typically protected by network segmentation. However, because they are assumed to be unreachable from the internet, they often have weaker security measures.
In many cases, these internal systems contain sensitive functionality that does not require authentication, assuming that only trusted internal components will interact with them. This makes them prime targets for Server-Side Request Forgery (SSRF) attacks.
Example: Accessing an Internal Admin Panel
Consider the same shopping application example from before. Suppose the back-end system has an administrative interface hosted at http://192.168.0.68/admin, which is only meant to be accessed from inside the company's private network.
An attacker can target an internal admin panel using SSRF:
Since the request originates from the application server (which is inside the organization's network), it may successfully access the private administrative interface, even though the attacker is external.
Private IP addresses are reserved address blocks used for internal network communication. Devices within a private network can communicate with each other using these addresses, but they cannot be accessed directly from the public internet.
Now consider this lab from Web Security Academy.
Lab: Basic SSRF against another back-end system
Lab Description
This lab has a stock check feature which fetches data from an internal system.
To solve the lab, use the stock check functionality to scan the internal 192.168.0.X range for an admin interface on port 8080, then use it to delete the user carlos.
Lab Solution
Access the check stock feature by clicking any product and using the check stock functionality as shown in the above screenshot.
Now check burp suite for the requests captured.
As shown in the screenshot above, the request selected contains the check stock feature.
Carefully note that as mentioned in the lab description, the address provided to us is not complete. To know the complete address where the admin interface is hosted, we will send this request to burp suite intruder and brute force for the correct address.
As shown in the above screenshot we replace the stockApi value with the URL to the IP given in the lab description which points to port 8080 to access the admin panel.
We replace the “X” with “1” and add the payload position over there as this will be replaced each time to check for the correct IP address.
In next step we set the payload as the numbers from 1 to 255 with step value as 1 as shown in the screenshot below.
The results from burp intruder are:
As can be seen in the results above, there is one request with status code 200 which means this is the successful request. The highlighted part is the correct IP address which hosts the admin panel over port 8080.
Now send this request to repeater.
Now in repeater, send the request and in the response look for the URL that will delete the user carlos.
Update the current value of stockApi with this URL and send the request.
This finally solves the lab.
3- Bypassing Blacklist-Based Input Filters in SSRF
Some applications attempt to prevent Server-Side Request Forgery (SSRF) by blocking requests containing specific hostnames (e.g., 127.0.0.1, localhost) or restricted paths (/admin). However, blacklist-based filtering is often weak and can be bypassed using various techniques :
1. Using Alternative IP Representations
Decimal notation:
2130706433(which equals127.0.0.1in decimal).Octal notation:
017700000001.Shorthand notation:
127.1(a valid alternative for127.0.0.1).
Example: Instead of using http://127.0.0.1/admin, try http://2130706433/admin.
2. URL Encoding & Other Encoding Techniques
URL encoding:
http://127%2E0%2E0%2E1/admin.Double encoding:
http://127%252E0%252E0%252E1/admin.Hex encoding:
http://0x7f.0x00.0x00.0x01/admin.Base64 encoding (if applicable):
aHR0cDovLzEyNy4wLjAuMS9hZG1pbg==(if the application allows decoding).
3. Case Variation Tricks
Some blacklist filters only block lowercase variations of keywords. If filtering is case-sensitive, you can try different capitalizations:
Bypassing
localhost:LoCaLhOsT,lOcAlHoSt.Bypassing
/admin:/AdMiN,/ADMIN.
Tip: Try a combination of encoding and case variation for better success!
4. Using Open Redirects & External URLs
If an application blocks direct requests to sensitive endpoints, you can bypass the filter by using an open redirect on a different domain that forwards the request to the restricted resource.
5. Leveraging Different Redirect Codes & Protocols
Web servers use HTTP status codes for redirections. Some SSRF filters fail when handling certain redirect codes or protocol changes. You can experiment with:
301 Moved Permanently
302 Found (Temporary Redirect)
307 Temporary Redirect (preserves the original HTTP method).
308 Permanent Redirect (similar to 301 but stricter).
6.Protocol Switching:
If an application blocks
http://127.0.0.1/admin, try redirecting from anhttps://URL instead.Some filters fail when handling
ftp://orfile://protocols.
Now consider this lab from Web Security Academy.
Lab: SSRF with blacklist-based input filter
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.
The developer has deployed two weak anti-SSRF defenses that you will need to bypass.
Lab Solution
Access the check stock feature by visiting any product and clicking the check stock button as shown in the screenshot below.
Now check burp suite for the request captured.
Send this request to burp suite repeater and replace the current value of stockApi with the back-end system URL as shown in the screenshot below.
Now send the request and analyse the response.
As can be seen, the request has been blocked, this means there is some anti-SSRF defense mechanism which is blocking the request.
Now try URL encoding “/” and replacing it with its URL encoded counterpart and also try case variation in case of “localhost”. Finally send the request and analyse the response as shown in the screenshot below.
Now try to replace “localhost” with “127.0.0.1” and also try case variation in “admin” leaving “/” URL encoded only. Send the request and analyse the response as shown in the image below.
Now try to replace URL encoded “/” with “/” itself and also try some other case variation in “admin” and “localhost” as shown in the screenshot below. Finally send the request and analyse the response.
This means that the SSRF attack was successful and that we have got the access to admin panel.
Look for the path that will delete the user carlos as shown in the screenshot below.
Modify the value of stockApi as shown in the screenshot below and send the request.
This finally solves the lab.
The logic behind the lab was using an SSRF payload and by-passing the anti-SSRF security mechanism using payload obfuscation.
Bypassing SSRF Filters via Open Redirection
In such a scenario, even if a URL filter is in place to block dangerous domains or internal resources (like localhost or 127.0.0.1), an open redirection vulnerability may still allow attackers to bypass these filters. This happens when the application allows users to supply URLs that the backend server follows, and it supports HTTP redirections (such as HTTP 301, 302, or 307).
If the URL contains a legitimate domain that passes the filter, but redirects to a malicious internal IP or service, SSRF can still occur.
Example Scenario:
Consider the following scenario in a vulnerable application:
The application allows users to check the stock of products from an external API. The user submits a request such as:
The URL /product/nextProduct contains a parameter path that redirects to any URL specified by the attacker:
In this case, it will redirect to http://evil-user.net.
An attacker can leverage this vulnerability to bypass the SSRF filter. Instead of providing a malicious internal URL (which would be blocked), they use the open redirection URL to reach an internal service or target:
The server will:
Validate the
stockApiparameter, which points to a legitimate domain (weliketoshop.net).Make a request to this external domain, which then redirects to
http://192.168.0.68/admin(an internal service).The application follows the redirection, accessing an internal administrative interface, bypassing internal access controls.
How This Works
The SSRF vulnerability works because the application:
Validates the initial domain (
weliketoshop.net), allowing it through the filter.Follows the redirect to an internal resource (
http://192.168.0.68/admin), which the attacker controls.
Now consider this lab from Web Security Academy.
Lab: SSRF with filter bypass via open redirection vulnerability
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://192.168.0.12:8080/admin and delete the user carlos.
The stock checker has been restricted to only access the local application, so you will need to find an open redirect affecting the application first.
Lab Solution
Click on any product and then access the check stock feature as shown in the screenshot below.
Now check burp suite for the intercepted request and send it to repeater.
Now try accessing the admin functionality as done in the screenshot below.
The response to the above request is:
This means the request to this internal resource is being blocked, hence we need to find an open redirection that can help us access this restricted resource.
On further analysis we get the next product button as shown below and clicking it captures the request for the same in burp suite.
As shown in the screenshot above, the request for the next product contains the query parameter path which provides the potential of a possible open redirection.
Open redirection means a security flaw in a web application that allows an attacker to manipulate where the application redirects a user.
Hence we try redirecting this to “google.com” as demonstrated below.
As can be seen, there is indeed an open redirection vulnerability that allows the attacker to control the redirection path.
Since the stockApi has access to the internal resources thus we can not redirect from this request itself but we copy the path of this request and then paste it in the stockApi parameter, further we append the internal path in the query parameter path. This is demonstrated in the screenshots below.
Now the response for the above request is:
Since the original value of the stockApi was URL encoded hence we encode this value also by selecting it and pressing ctrl+U.
The request is modified as:
The response for the above request is:
This shows that we have successfully got access to the admin panel.
Now we look for the request that deletes user Carlos and modify the stockApi value accordingly as demonstrated in the screenshots below.
This finally solves the lab.
The logic behind the working of this attack is that, the stockApi parameter had access to the internal resources of the server but it did not allow direct access to them due to strict validation of the request. Thus we look for the request that has an open redirection vulnerability which means that the user has control over the URL where redirection takes place.
In this case the redirection was there in the “next product” request. We copy the path of this request and replace it with the value of stockApi since stock checking feature has access to internal resources and thus redirection to internal resources was not possible from the “next product” request itself.
Finally we replace the path parameter with the value of the path to the internal resource that is admin in this case. This finally gives us the access to the admin panel and the lab is further solved as per the steps explained above.
Blind SSRF vulnerabilities
What is blind SSRF?
Blind SSRF vulnerabilities occur if you can cause an application to issue a back-end HTTP request to a supplied URL, but the response from the back-end request is not returned in the application’s front-end response.
What is the impact of blind SSRF vulnerabilities?
The impact of blind SSRF vulnerabilities is often lower than fully informed SSRF vulnerabilities because of their one-way nature. They cannot be trivially exploited to retrieve sensitive data from back-end systems, although in some situations they can be exploited to achieve full remote code execution.
How to find and exploit blind SSRF vulnerabilities
The most reliable way to detect blind SSRF vulnerabilities is using out-of-band (OAST) techniques. This involves attempting to trigger an HTTP request to an external system that you control, and monitoring for network interactions with that system.
Finding hidden attack surface for SSRF vulnerabilities
1. Partial URLs in Requests:
The application might accept user input for URLs, but only a portion of the URL (like the hostname or part of the path) is stored in a request parameter. The server then constructs the complete URL by combining this user input with a pre-defined base URL.
2. URLs within Data Formats:
The application might accept and process data in formats like XML that allow embedding URLs. When the server parses this data, it might also unintentionally request the embedded URLs.
3. SSRF via the Referer Header:
The application might use analytics software that logs the “Referer” header in requests. This header indicates the webpage that linked to the current request. Some analytics software might even visit the URLs found in the Referer header.
Attackers can potentially craft a webpage containing a malicious URL and trick a user into visiting it. The Referer header would then contain the attacker’s URL, which might get unintentionally requested by the analytics software if it’ not properly validated.
Last updated