SSRF 101-Everything you need to know about SSRF attacks
Server-Side Request Forgery (SSRF) is a security vulnerability that has garnered significant attention in recent years due to its potential to wreak havoc on web applications and backend systems. In this blog post, we will explore SSRF in-depth, starting with its definition and impact, and then delve into common attack scenarios, defenses, and detection techniques.
What is SSRF?
Imagine you’re ordering food online through a website. When you click on a link to view the menu, the website sends a request to the restaurant’s server to fetch the menu and display it for you. Now, SSRF is like a sneaky waiter who tricks the website into sending a request to their kitchen instead of the restaurant’s kitchen. As a result, the sneaky waiter can access the restaurant’s secret recipes, which you shouldn’t normally have access to.
The Impact of SSRF Attacks
Example 1 — Data Exposure: Think of SSRF as a way for someone to peek into rooms they’re not allowed to enter. If they use SSRF to access the HR department’s confidential files, they might discover sensitive employee information like salaries and personal data.
Example 2 — Service Disruption: Imagine a company’s website is hosted on a server. An attacker uses SSRF to make the server send countless requests to itself, overloading it with requests like a never-ending line at a food truck. This can cause the website to slow down or even crash, making it unavailable to users.
Example 3 — Security Bypass: Suppose a secure website only allows access to certain areas after you log in. An attacker with SSRF powers can skip the log inprocess and directly access restricted sections, like the admin panel, without the proper credentials.
Common SSRF Attacks
Regular SSRF:
Imagine you have a blog where you can input a URL to fetch a preview of a website. An attacker enters a URL like “http://malicious-site.com/secret-info" in the input field. The blog’s server, fooled by the attacker, fetches the secret information from the malicious site and displays it.
SSRF Attacks Against the Server:
In this scenario, the attacker tricks the server into sending a request to itself, perhaps to an admin panel. The server, thinking it’s a legitimate request, complies, and the attacker gains unauthorized access.
SSRF Attacks Against Other Backend Systems:
Picture a website connected to an internal employee database. An attacker uses SSRF to send requests to this internal database, gaining access to sensitive employee records.
Circumventing Common SSRF Defenses
SSRF with Blacklist-Based Input Filters:
Suppose a website blocks requests to “example.com.” The attacker, knowing this, uses an IP address instead of the domain name or employs URL encoding to make the request look different, successfully bypassing the filter.
SSRF with Whitelist-Based Input Filters:
If a website only allows requests to trusted domains like “trusted.com,” an attacker might exploit vulnerabilities on a trusted domain to launch SSRF attacks on other systems.
Bypassing SSRF Filters via Open Redirection:
An attacker might find a vulnerability that allows them to manipulate where the website sends SSRF requests. For instance, they could craft a link that appears harmless but leads to malicious destinations.
Blind SSRF Vulnerabilities
Think of blind SSRF as sending secret Morse code messages. Even though you can’t see the actual message, you can still detect its presence by measuring the time it takes for a response. If it’s slower, you know something’s up.
Blind SSRF vulnerabilities occur when an application does not directly reveal the SSRF response to the attacker. Instead, the attacker needs to infer the results indirectly. Here are a couple of examples to help you understand blind SSRF:
1. Timing-Based Blind SSRF:
Imagine you have a web application that fetches data from an internal server and displays it. However, this application doesn’t directly show you the response content. Instead, it only tells you whether the response took a long time (indicating a successful fetch) or a short time (indicating a failed fetch).
Now, an attacker wants to see if there’s a blind SSRF vulnerability. They send a request to a URL that points to the internal server and measure the time it takes for the response.
- If it takes a long time, the attacker infers that the SSRF request was successful because the application had to wait for a response.
- If it’s a short response time, the attacker infers that the SSRF request failed or didn’t return any valuable data.
In this way, the attacker can indirectly determine the existence of SSRF and potentially the type of data available on the internal server based on response timing.
2. Out-of-Band (OAST) Blind SSRF:
In this scenario, the attacker cannot see the SSRF response directly, but they can send the SSRF request in a way that triggers an action on an external server controlled by the attacker.
For example, consider a web application that can fetch and display images from remote URLs. The attacker crafts a request to fetch an image from an internal server, but instead of trying to view the image, they create a URL that, when accessed, triggers a request to an external server controlled by the attacker.
- The attacker monitors the server for incoming requests. If they receive a request from the vulnerable application, they can infer that the SSRF request was successful, even though they couldn’t directly see the internal server’s response.
These examples illustrate how attackers can exploit blind SSRF vulnerabilities to indirectly gather information or confirm the presence of SSRF in an application without directly viewing the responses. To defend against blind SSRF, it’s important to monitor and control outgoing SSRF requests and implement strict access controls on internal resources.
Finding Hidden Attack Surface for SSRF Vulnerabilities
Imagine you’re a detective searching for clues. You inspect every nook and cranny of a website’s code and input fields, looking for anything that seems out of place, like a hidden tunnel (an SSRF vulnerability) that shouldn’t be there. Automated tools help you by scanning the website for these hidden tunnels.
In conclusion, SSRF vulnerabilities are like sneaky tricks that attackers use to manipulate a website’s requests and access things they shouldn’t. By understanding how SSRF works and using the right defenses, you can protect your applications and systems from these digital tricksters.
