SSRF
Last updated
Last updated
SSRF is a type of web attack where a server can make requests on behalf of an attacker.
Server-side Request Forgery (SSRF) is a vulnerability that allows the web server to make requests for the attacker to internal or external systems.
Think of SSRF like using a proxy or a VPN. Imagine a user wanting to access a specific resource. Instead of directly requesting it, they go through a proxy or VPN server. This intermediary then sends the request to the resource on behalf of the user, gathers the results, and finally sends those results back to the user. SSRF operates in a somewhat similar fashion.
Consider an application that displays the top deals for online shopping platforms such as Amazon.
Now, picture this application as . In this scenario, the application has a specific endpoint called /amazon. This endpoint is responsible for fetching discounts across different categories from another application, let’s call it . The catch here is that the application doesn’t thoroughly check the URL it’s receiving before proceeding with the fetch operation.
So the HTTP request would look something like this:
In this case, the application would fetch the data from and retrieve the detailed data.
However, the URL () can be replaced with any other URL. When the application receives the URL, the server will make a request to the URL and return the response to the user. This is where the SSRF vulnerability comes into play.
An effective SSRF attack can lead to unauthorized activities or the ability to reach data within the organization. This can occur within the compromised application or even extend to other backend systems it interacts with. In more concerning scenarios, the vulnerability in SSRF might permit an attacker to execute arbitrary commands, essentially gaining control over certain actions.
If an SSRF exploit is used to establish connections with external third-party systems, it could potentially trigger malicious follow-up attacks. These attacks might cleverly seem to originate from the organization that’s running the vulnerable application, adding another layer of complexity and danger to the situation.
There are two types of SSRF attacks: blind and basic. Basic SSRF attacks occur when the attacker can see the response from the server.
Blind SSRF attacks occur when the host server does not return visible data to the attackers. They work by focusing on performing malicious actions rather than accessing sensitive data. An attacker may tamper with user permissions or sensitive files on the server. For instance, the attacker might change the URL for the API call to induce the server to retrieve a large file repeatedly. Eventually, the server could crash, causing a denial of service (DoS).
Sensitive data is the most popular target of SSRF attacks. Attackers typically submit malicious URLs to induce the server to return system information, allowing the attackers to escalate the attack. For example, an attacker might obtain credentials to access the server and create damage the higher the privilege level of the exposed credentials, the higher the risk. If an attacker obtains admin credentials, it could control the whole server.
Denial of service attacks flood the target server with large volumes of requests, causing it to crash. DoS attacks are common, with many real-world examples. An SSRF-based DoS attack targets the internal servers of a network.
Internal servers are typically vulnerable to DoS attacks because they don’t support large traffic volumes. Their low-bandwidth configuration makes sense because they normally receive far fewer requests than a public-facing server. Attackers can mount SSRF attacks to send large traffic volumes to the target system’s internal servers, taking up the available bandwidth and crashing the servers.
In this attack an application processes user supplied URLs and does not verify or sanitize the back-end response received from remote servers before sending it back to the client. An attacker can send crafted queries to a vulnerable web application to proxy attacks to external Internet facing servers, intranet devices and the web server itself. The responses, in certain cases, can be studied to identify service availability like open ports , banner versions etc.
It allows attackers to abuse available functionality in most web applications to scan port of intranet and external Internet facing servers, fingerprint internal (non-Internet exposed) network aware services, perform banner grabbing, identify web application frameworks, exploit vulnerable programs, run code on reachable machines, exploit web application vulnerabilities listening on internal networks, read local files using the file protocol and much more.
An attacker can use SSRF to fetch metadata from the cloud instance. This metadata can be used to get the credentials of the cloud instance. The attacker can then use these credentials to access the cloud instance and perform malicious activities.
An attacker can use SSRF to perform Remote Code Execution (RCE) on the server. This can be done by exploiting the SSRF vulnerability to make a request to a local service running on the server. The attacker can then use this service to execute arbitrary commands on the server.
Certain applications utilize server-side analytics software to monitor their visitors' activities. This software commonly records the Referrer header within incoming requests, as it holds special significance for tracing the origins of incoming links. Frequently, the analytics software goes a step further and actually visits any third-party URLs found in the Referrer header. This practice is generally aimed at dissecting the content of the sites that referred the traffic, encompassing elements like the anchor text utilized in those incoming links. Consequently, the Referrer header frequently emerges as a promising playground for potential SSRF vulnerabilities.
SSRF is a serious vulnerability that can be exploited to perform a variety of attacks. It is important to understand how it works and how to prevent it. The best way to prevent SSRF is to validate all user input before using it in a request. This includes validating the URL, the HTTP method, and any other parameters that may be used in the request. It is also important to use a whitelist approach when validating user input. This means that you should only allow certain characters in the input and reject anything else. For example, if you are expecting a URL, you should only allow letters, numbers, and a few special characters such as ., -, and _. You should also make sure that the URL is valid by checking if it starts with http:// or https://. If it does not, then you should reject it. Finally, you should make sure that the URL is not a local IP address or a loopback address. If it is, then you should reject it.
Name: Proxy Lharba
Description: The flag is in this endpoint: http://127.0.0.1:1337/secret, can you get it?
URL: