What is SSRF?
SSRF (Server-Side Request Forgery) is a web application vulnerability that allows an attacker to cause the server to make unintended requests to other systems or websites on behalf of the vulnerable application.
In an SSRF vulnerability, the server fetches or processes a resource from a user-supplied URL without properly validating or sanitizing the input. This can allow an attacker to craft malicious URLs that cause the server to access internal systems or resources that should not be accessible from the web application.
The impact of an SSRF vulnerability can range from leaking sensitive data, such as files or metadata, to conducting port scanning or attacking other systems on the network. In some cases, SSRF vulnerabilities can even lead to remote code execution on the server or other systems, depending on the functionality of the vulnerable application.
SSRF vulnerabilities typically arise due to insufficient input validation and sanitization of user-supplied data that is used to fetch or access resources. Applications that allow users to upload files or images by providing a URL, or those that make outgoing requests based on user input, are particularly susceptible to SSRF vulnerabilities if the input is not properly validated.
Let’s understand with the help of an example:
Imagine you run a website that allows users to upload images. When a user uploads an image, your server fetches the image from the provided URL and stores it. This is a common feature on many websites.
Now, let’s say there’s a vulnerability in your code that doesn’t properly validate or sanitize the user-supplied URL. A malicious user could exploit this vulnerability by providing a URL that doesn’t point to an image but instead points to an internal system on your network or even another website on the internet.
Since your server trusts and fetches the provided URL, it could inadvertently leak sensitive information or be used as a pivot point to attack other systems.
For example, if the malicious user provides a URL likehttp://192.168.1.100/sensitive_data.txt (assuming this is an internal IP address on your network), your server would fetch the contents of that file and potentially expose sensitive data.
Or, if the user provides a URL likehttp://example.com/admin_login (a website you don’t control), your server would attempt to fetch that page, potentially revealing your server’s IP address and other information to the target website.
SSRF vulnerabilities can also be used to scan internal networks, perform port scanning, or even launch other types of attacks, depending on the vulnerable application’s functionality.
The root cause of SSRF vulnerabilities is the lack of proper input validation and sanitization. Developers should always validate and sanitize user-supplied data, especially when it involves making external requests or accessing internal resources.
Common SSRF attacks
SSRF against the server
In a scenario where a server is under attack by SSRF, the attacker manipulates the application to make an HTTP request back to the very server hosting the application itself, utilizing its loopback network interface. This maneuver typically involves inserting a URL with a hostname such as 127.0.0.1 (an IP address reserved for pointing to the loopback adapter) or localhost (a commonly recognized name for the same adapter).
Let’s take a real-world example to grasp this better: Think of a shopping app where users can check if a specific item is available in a certain store. To fetch this information, the app needs to query various backend REST APIs. It does so by passing the URL of the relevant backend API endpoint through a frontend HTTP request. So, when a user checks the stock status of an item, their browser sends out 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%3D1This action prompts the server to execute a request to the designated URL, fetching the stock status and relaying it back to the user.
Now, consider this scenario: an attacker can manipulate 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/adminThe server retrieves the contents of the /admin URL and forwards them to the user.
Now, here’s where it gets interesting: an attacker may attempt to access the /admin URL, which typically hosts administrative functionalities accessible only to authenticated users. Initially, the attacker won’t find anything noteworthy, as access is restricted. However, when the request to the /admin URL originates from the local machine, standard access controls are circumvented. In this scenario, the application grants unrestricted access to the administrative features, as the request seems to stem from a trusted source.
SSRF attacks against other back-end systems
In certain scenarios, the application server possesses the capability to engage with backend systems that are inaccessible to regular users. These systems typically boast non-routable private IP addresses and are shielded by the network topology, often resulting in a comparatively weaker security posture. Furthermore, internal backend systems commonly harbor sensitive functionalities that, if accessed, can be utilized without the need for authentication.
Expanding on the previous example, envision an administrative interface residing at the backend URL https://192.168.0.68/admin. Leveraging the SSRF vulnerability, an attacker could craft and submit the following request, ultimately gaining access to the administrative interface:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://192.168.0.68/adminSSRF with blacklist-based input filters
In situations where applications employ filters to block input containing hostnames like 127.0.0.1 and sensitive URLs such as /admin, attackers can often bypass these restrictions by employing the following techniques:
- Alternative IP Representations: Utilize alternative representations of the loopback IP address 127.0.0.1, such as 2130706433, 017700000001, or 127.1. These representations may evade simple string-based filters while still achieving the same effect.
- Registering Custom Domain Names: Register a custom domain name that resolves to 127.0.0.1. For instance, using a domain like spoofed.burpcollaborator.net can serve this purpose effectively, enabling attackers to bypass hostname-based filters.
- Obfuscation Techniques: Employ obfuscation methods such as URL encoding or case variation to obfuscate blocked strings like localhost or /admin. By altering the representation of these strings, attackers can potentially bypass pattern-based filtering mechanisms.
- Redirects via controlled URLs: Provide a URL controlled by the attacker that redirects to the target URL. Experiment with different redirect codes and protocols to bypass anti-SSRF filters. For instance, switching from an http to a https URL during the redirect process has been observed to circumvent certain filter configurations effectively.
In the Portswigger lab, you’ll navigate through a product page and decide to check its stock availability. As you click the “Check stock” button, you intercept the ensuing request using Burp Suite and direct it to Burp Repeater for further examination. In an attempt to manipulate the request, you change the URL in the stockApi parameter to http://127.0.0.1/, only to find that the request is blocked. Undeterred, you bypass this obstacle by substituting the URL with http://127.1/, successfully circumventing the block. However, when you attempt to access the administrative interface by appending /admin to the URL (http://127.1/admin), your efforts are once again thwarted as the URL is blocked. Determined to proceed, you resort to obfuscation tactics, double-URL encoding the character “a” to %2561. This clever maneuver allows you to access the admin interface clandestinely, where you proceed to delete the target user.
SSRF with whitelist-based input filter
In scenarios where applications enforce input validation through whitelisting permitted values, attackers can exploit inconsistencies in URL parsing to potentially bypass such filters. The URL specification offers several features that are often overlooked during ad-hoc parsing and validation, allowing attackers to craft malicious URLs that slip through the filter:
- Embedding Credentials: Attackers can embed credentials in a URL before the hostname using the “@” character. For instance, https://expected-host:fakepassword@evil-host can deceive the filter into accepting the URL.
- Utilizing URL Fragments: The “#” character can be utilized to indicate a URL fragment. For example, https://evil-host#expected-host can manipulate the URL parsing and potentially bypass the filter.
- Leveraging DNS Naming Hierarchy: By incorporating required input into a fully qualified DNS name controlled by the attacker, such as https://expected-host.evil-host, attackers can manipulate the parsing process to their advantage.
- URL-Encoding: Attackers can URL-encode characters to confuse the URL-parsing code. This is especially effective if the code handling the filter treats URL-encoded characters differently from the backend HTTP request. Additionally, double-encoding characters may exploit servers that recursively URL-decode input, leading to further discrepancies.
- Combining Techniques: Attackers can combine these techniques, creating sophisticated URLs that increase the likelihood of bypassing the filter effectively.
During a penetration testing scenario in this lab, you navigate to a product page and decide to inspect its stock availability.
As you click the “Check stock” button, you intercept the ensuing request using Burp Suite and analyze it in Burp Repeater.
Upon attempting to modify the URL in the stockApi parameter to http://127.0.0.1/, you notice that the application parses the URL, extracts the hostname, and validates it against a whitelist.
However, undeterred, you experiment by changing the URL to include embedded credentials, such as http://username@stock.weliketoshop.net/. Remarkably, this modification is accepted, revealing that the URL parser indeed supports embedded credentials.
Curious to push further, you append a “#” to the username, only to find the URL rejected. In a creative move, you double-URL encode the “#” to %2523 and are met with an unexpected “Internal Server Error” response—an indication that the server might have attempted to connect to a “username.”
Sensing an opportunity, you craft a URL targeting the admin interface, effectively deleting the target user, with the modified URL reading: http://localhost:80%2523@stock.weliketoshop.net/admin/delete?username=carlos.
Bypassing SSRF filters via open redirection
In certain cases, filter-based defenses can be circumvented by exploiting an open redirection vulnerability.
Consider a scenario where the user-submitted URL undergoes strict validation to prevent malicious exploitation of SSRF behavior. Despite this, if the application allowing URLs contains an open redirection vulnerability, it presents an opportunity for bypassing the filter. By crafting a URL that meets the filter’s criteria and triggers a redirection to the desired backend target, attackers can potentially exploit this vulnerability.
This technique relies on the capability of the backend API to support redirections. By leveraging the open redirection vulnerability, attackers can manipulate the flow of requests, leading them to unintended destinations beyond the scope of the filter. Therefore, it’s crucial for organizations to implement robust security measures, including thorough validation of user inputs and mitigation of open redirection vulnerabilities, to safeguard against such exploitation attempts.
/product/nextProduct?currentProductId=6&path=http://evil-user.net
redirected to:
http://evil-user.net
You can exploit the open redirection vulnerability to bypass the URL filter and subsequently leverage the SSRF vulnerability in the following manner:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/adminThis SSRF exploit capitalizes on the application’s initial validation process, which verifies that the supplied stockAPI URL resides within an allowed domain, thereby passing the filter. However, by subsequently requesting the supplied URL, the application inadvertently triggers the open redirection vulnerability. As a result, the application obediently follows the redirection, leading to a request made to the internal URL specified by the attacker. This chain of events facilitates unauthorized access to internal systems, allowing attackers to manipulate and potentially exploit sensitive resources as per their objectives.
Conclusion
In conclusion, server-side request forgery (SSRF) vulnerabilities pose significant risks to web applications, enabling attackers to manipulate server-side requests and potentially interact with internal systems or external resources. Through techniques such as URL parsing inconsistencies, open redirection vulnerabilities, and bypassing input filters, attackers can exploit SSRF vulnerabilities to bypass security measures and carry out unauthorized actions. It is imperative for organizations to implement robust security measures, including comprehensive input validation, strict access controls, and prompt patching of known vulnerabilities, to mitigate the risk of SSRF attacks effectively. Additionally, ongoing security awareness training for developers and penetration testing to identify and address SSRF vulnerabilities are crucial steps towards enhancing the overall security posture of web applications. By proactively addressing SSRF vulnerabilities, organizations can minimize the likelihood of exploitation and safeguard their sensitive data and resources from malicious actors.
References
Top 10 Web Hacking Techniques of 2017 | PortSwigger Research
Server-Side Request Forgery – SSRF Security Testing | HackerOne
Intro to SSRF – Vickie Li’s Security Blog
SSRF In The Wild – Vickie Li’s Security Blog
About me
Hello, I’m Harshi Gupta, a seasoned penetration tester with expertise in both internal and external assessments. Cybersecurity is not just a career path for me; it’s my hobby and passion. With a wealth of experience in identifying and mitigating security vulnerabilities, I am dedicated to ensuring the resilience of organizations’ digital assets. For networking opportunities and engaging discussions, feel free to reach out to me via LinkedIn and Twitter.