What is Server-Side Request Forgery (SSRF)?

Published on: May 14, 2024

.

10 min read

Server-side request forgery (SSRF) is a security hole in web security that lets an intruder direct requests made by the server-side application to an unauthorized destination. SSRF occurs when a vulnerable server-side application is tricked into accessing or interacting with resources that are not directly accessible to the attacker. These can be internal services, databases, or cloud-specific metadata.

In an SSRF attack, an attacker forces the server to establish a connection to internal-only services located within the IT framework of the company. The intruder exploits the trust placed in the server by crafting a malicious URL or input that the server processes. This effectively bypasses security measures and access controls. SSRF attack leads to unauthorized actions, data exposure, or even full compromise of the server and its connected systems.

SSRF attacks might be able to compel the server to establish a connection with arbitrary external systems. As a consequence, sensitive information like authorization credentials can leak and even full compromise of the server and its surrounding elements. In an example scenario, the vulnerable application relies on user input, like a URL, to determine where to fetch data. In a web app fetching images from URLs, an attacker could input a URL like http://localhost/admin to exploit vulnerability and access sensitive data. Unaware of the trickery, the server trusts the user input and retrieves data from the attacker-specified URL.

The following topics are going to be discussed in this article:

• How does Server-Side Request Forgery (SSRF) work?
• Why does SSRF happen?
• Who are the typical targets of SSRF Attacks?
• What are the potential impacts and risks associated with SSRF vulnerabilities?
• What are the different types of SSRF attacks?
• How can SSRF vulnerabilities be detected?
• How can Server-Side Request Forgery (SSRF) be prevented?
• What are the common mitigation methods for SSRF vulnerabilities?
• Observed examples of SSRF attacks?
• What is the difference between SSRF and other similar vulnerabilities?
• Difference between Server-Side Request Forgery (SSRF) and Cross-Site Request Forgery (CSRF)
• Difference between Server-Side Request Forgery (SSRF) and Cross-Site Scripting (XSS)
• Difference between Server-Side Request Forgery (SSRF) and Remote Code Execution (RCE)

How does Server-Side Request Forgery (SSRF) work?

The goal of SSRF attacks is to fool a server into sending requests to random IP addresses. The main steps of the SSRF attack are as follows:

1. Injecting the Malicious URL: The attacker identifies a vulnerable application that accepts user-controlled URLs. This could be a form for image uploads, weather data fetching, or any functionality that fetches external resources. This URL is designed to cause the server to make a request to a specific resource, which the attacker wants to access or manipulate. The attacker then injects the malicious URL disguised as legitimate input.

2. Application Request: Unaware of the trickery, the application processes the user input and initiates a request to the URL provided by the attacker, without proper validation or sanitization.

3. Server Fetches Data: The server, trusting the application, acts on the request and fetches data from the attacker-specified URL. This request is treated as a normal HTTP request by the server. In fact it may point to internal resources, external systems the server shouldn't access, or even malicious scripts.

4. Server Response: The server responds to the request, providing the requested data or performing the requested action. The attacker can directly observe the response from the server, which may include sensitive information or access to internal resources.

5. Gain: Depending on the attacker's goals, the fetched data or executed script can lead to various consequences. These might include internal information disclosure (server configuration, databases), denial-of-service attacks on internal systems, remote code execution on the server, and pivoting to launch further cyber attacks within the network.

For instance, on a municipality website, the web application queries its server for the hour of the next bus to come to display. It can accomplish this by sending a URL and an API request to the server from the user's browser employing a REST API.

The request might look like the following snippet:

(POST /municipality/schedule HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 123

busApi=http://data.municipality.com:8080/transportation/hours/check%2FcurrentDateTime%2D3%26busId%2D1 )

The attacker can change this to the following;

(busApi=http://localhost/admin)

This will cause the server to display the contents of the admin folder to the attacker. Even though the attacker is not permitted, the request circumvents standard access controls and exposes the data because it is run within the file system of the server.

Why does SSRF Happen?

The primary purpose of the SSRF attack is to gain access to sensitive data. This could be performed directly by forcing it to write data to an attacker-supplied URL. Indirectly, it can be done by exploiting a vulnerability that can be used to steal data. Some common SSRF occurrence reasons are listed below:

• Unvalidated User Input: SSRF attacks happen when a web application fails to validate user input when fetching a resource. This allows an attacker to manipulate the URL or provide an entirely new URL, which the server then reads or submits, allowing the attacker to read server data, connect to internal services, or send post requests to private internal services.

• Trust Relationships: When a trust relationship in a vulnerable application allows access to internal systems, sensitive data, or even app functionality. It can be due to the application server interacting with private backend systems not intended for access by external users.

• Lack of Proper Security Controls: When an engineer doesn't implement proper security controls because they assume that the network topology protects internal systems.

• Unsecured APIs: Through unsecured APIs that allow user-controlled URLs to be passed over the API and honored and processed by the back-end server.

• Unvalidated URLs: When a web application does not properly validate URLs before sending requests to them. URL manipulation may happen.

• Unsecured Server Configuration: When a server is not properly configured for security. Letting requests only from specific hosts or IP addresses for instance.

• Unvalidated Data and Parameter: When a web application does not properly validate data and parameters before sending requests to them.

• Unsecured Network Configuration: When a network is not properly configured like not having proper firewall rules or access controls.

• Unsecured Services: When a service is not properly secured like not having proper authentication or authorization controls.

Who are the Typical Targets of SSRF Attacks?

Web applications with improperly set access controls, exposed third-party services, and unreliable URL parsers are frequently the targets of SSRF attacks. SSRF attacks don't discriminate - any organization relying on web applications with user-controlled inputs is a potential target. Attackers exploit weaknesses in web applications that process user-provided URLs. This could be anything from a photo upload form in an e-commerce store to a social media post where users share links. The most common targets of SSRF attacks are listed below:

• Apps on the web that let users submit URLs to import files (such as papers or photos).

• Programs utilizing open-source libraries or services for URL parsing or request processing.

• Inadequate input validation and data sanitation on some systems allows attackers to change URLs and carry out unwanted operations.

What are the Examples of SRRF Attacks?

They are mainly organizations with user-controlled URLs including e-commerce platforms, cloud-based services, and social media apps. If functionalities like image uploads or product linking from external sources have vulnerabilities, attackers can exploit them to access internal systems or steal customer data. Integrations with external applications or data sources can be manipulated if not secured properly. This is an example of a compromised cloud environment. Another example is social media applications with features that let users share links that can be targeted to spread malware or steal login credentials. By becoming aware of the typical targets of SSRF attacks, you may more effectively spot possible weaknesses in your web app and take the appropriate precautions to keep your systems safe.

What are the potential impacts and risks associated with SSRF vulnerabilities?

Server-side request forgery vulnerabilities can have significant and far-reaching impacts on the security and integrity of an organization's systems and data. The potential consequences of a successful SSRF attack are given below:

• Unauthorized Access to Data: Intruders access sensitive data, including internal systems, databases, and cloud services. This can lead to the exposure of confidential information, such as user credentials, financial data, or intellectual property.

• Cross-Site Port Attack (XSPA): SSRF attacks enable attackers to scan the network for open ports and potentially execute cross-site port attacks. This results in further exploitation of vulnerabilities and unauthorized access to internal systems.

• Denial of Service (DoS) Attacks: SSRF attacks can be employed to flood internal servers with large volumes of requests, causing them to become unavailable and potentially leading to a DoS attack. This can be particularly damaging for internal servers that are not designed to handle high traffic volumes.

• Remote Code Execution (RCE): SSRF attacks can provide a means for attackers to execute arbitrary code on internal systems. It can lead to a complete takeover of the system in the worst case.

• Embedding Malware: If an attacker gains access to internal servers through an SSRF attack, they can embed malware onto the server, which can then spread to other connected systems.

• Data Exposure: SSRF attacks can result in the exposure of internal systems and services. It can let adversaries access and manipulate data without being detected.

• Trust Relationship Abuse: SSRF attacks can exploit trust relationships between internal systems. This may let intruders bypass security controls.

• Increased Risk of Further Attacks: SSRF attacks can provide a foothold for attackers to launch further attacks, such as SQL injection, cross-site scripting (XSS), or other types of web application attacks.

• Reputation Damage: A successful SSRF attack can damage an organization's reputation and lead to loss of customer trust and confidence.

• Financial Losses: SSRF attacks can result in significant financial losses due to the exposure of sensitive data, disruption of business operations, and the need for costly remediation and security measures.

• Legal and Compliance Issues: SSRF attacks can lead to legal and compliance issues, including non-compliance with data protection regulations and potential legal action against the organization.

• System Compromise: Complete compromise of internal systems. This can cause a loss of control over the system and the data inside.

• Rise of Costs: The need for additional security measures, remediation, and potential legal and compliance expenses.

What are the Types of SSRF Attacks?

SSRF attacks can be categorized into many forms according to the way the hacker communicates with the server and obtains data. The three basic types of SSRF attacks are standard, blind, and time-based blind. These types of SRRF attacks are outlined below:

1. Standard SSRF Attack: The attacker injects a malicious URL as part of the user input. It triggers the server to request the specified resource. By watching the server's response in real-time, hackers can learn details about the internal network. This includes how to access services and to retrieve data.

2. Blind SSRF Attack: Intruders do not directly receive the response from the server. Instead, they indirectly confirm the success or failure of the SSRF attack by observing changes in the application's behavior. Hackers submit a crafted input and force the server to request an external or internal resource. They are for observable changes in the application's activity. This includes differences in error messages, response times, or other side effects. This information helps them infer whether the SSRF was successful, even though they don't directly see the response.

3. Time-Based Blind SSRF Attack: This type of SSRF attack involves exploiting delays in the server's responses to infer the success or failure of the SSRF without directly seeing the response. Similar to other SSRF attacks, hackers incite the server to request an internal or external resource by submitting fraudulent input. They monitor the amount of time it takes for the application to respond. Response times that are delayed could mean the execution of SSRF was functional. To collect details about the internal network or resources, they monitor the time delays and iteratively modify the payload.

What are the Differences between Each SSRF Attack Types?

Below is a table comparing the types of SSRF attack:

Aspect	Standard SSRF Attack	Blind SSRF Attack	Time-Based Blind SSRF Attack
Interaction with Server	Attacker directly observes server response.	Attacker indirectly observes changes in behavior.	Attacker indirectly observes changes in response time.
Observer Receives Response?	Yes	No	No
Detection Method	Direct observation of server response.	Observing changes in application behavior.	Observing changes in response time.
Inference of Success/Failure	Directly based on received response.	Based on changes in behavior indicating success/failure.	Based on delays in response time.
Observables	Server response contents, network data access patterns.	Application behavior changes (e.g., error messages).	Time delays in application response.
Payload Manipulation	N/A	Crafting payloads to trigger observable changes.	Crafting payloads to exploit time delays.
Example Use Cases	Reconnaissance, data extraction.	Indirect confirmation of SSRF success/failure.	Inference of SSRF success based on time delays.

Table 1. Comparison of SSRF Attack Types

How can SSRF Vulnerabilities be Detected?

Depending on whether SSRF vulnerabilities have been identified or unresolved, there are different approaches for detecting them. If you only use commercial or open-source software and do not develop software of your own, you may find it enough to identify the exact version of the system or application that you are using. If the identified version is vulnerable to SSRF, you can assume that you are susceptible to that SSRF vulnerability. You can identify the version manually or use a suitable security tool, for example, software composition analysis (SCA) software in the case of web applications or a network scanner in the case of networked systems and applications.

If you develop your own software or want to potentially find unknown SSRF vulnerabilities like zero-days in known applications, you must be able to successfully exploit the SSRF vulnerability to be certain that it exists. In these situations, you have two options: utilize a security testing program that can automatically expose vulnerabilities, or carry out manual penetration testing with the assistance of security analysts or penetration testers. This is possible for web security testing only.

When dealing with custom software, note that server-side request forgery vulnerabilities are not easy to detect using simple tools because finding them requires a combined approach. Just by having access to these servers, you might be able to find several SSRF flaws that involve connection to other servers. This is the way that many SSRF vulnerabilities are detected by Acunetix and Netsparker. When a scan results in an HTTP request being sent by your application to the external listener service, which is included in both of these SQL injection detection tools, you have evidence of an SSRF weakness.

However, in the case of SSRF attacks that target the web application server itself or internal services only, such a third-party service is not sufficient. In these situations, you have to see if you can access common local resources, including files that are known to be publicly available on the server. This can be automated with professional tools, but additional penetration testing is always recommended to detect less common cases.

How can Server-Side Request Forgery (SSRF) be prevented?

SSRF prevention techniques for developers are listed below:

• Whitelisting: Limit access to known domains, IP addresses, or API endpoints. Whitelisting is a security feature that restricts a server-side program's access to just certain, approved domains or IP addresses. It will be harder for hackers to make requests to unauthorized domains through an SSRF vulnerability.

• Restrict request protocols: Control request protocols on APIs by blocking requests made using uncommon protocols such as ftp:/, gopher:/, and file:/. Typically, queries are delivered over HTTPS or HTTP, but since FTP and GOPHER are not frequently used, it is crucial to prevent requests made using them. By blocking the FILE protocol, attackers cannot access sensitive files.

  Include a check in the code that confirms the protocol used in the request URL in order to prevent SSRF attacks by limiting request protocols. If the protocol is not one of the allowed protocols (such as "https:" or "http:"), an error message is returned and the request is denied. Using the a parse function, a script can verify the protocol of the URL supplied in the request and compare it to the protocols in the whitelist. An error message is sent back and the request is stopped if the protocol is not in the whitelist. The validation/prevention process may be more complex in real-world scenarios by the way.

• Establish a strong allowlist: Make sure your application only accesses resources that are authorized by using an allowlist to validate IP addresses and DNS names. It will be harder for hackers to access resources. With a strong allowlist, SSRF attacks are prevented by allowing access to a whitelist of IP addresses and DNS names that the application is permitted to use. By guaranteeing that the program can only send requests to reliable resources, this helps prevent SSRF attacks. For instance, if a web app needs to retrieve information from an API, an attacker could try to exploit an SSRF vulnerability in the application to retrieve sensitive information from a different one. A function can extract the host from the URL and check it against the allowlist. If the host is not in the allowlist, the function returns False, and the request is rejected.

• Recognize DNS rebinding: Developers frequently make the error of adhering to this method. Convert the hostname supplied to an IP address. Verify if it's an internal IP address. If the request is internal, discard it. If not, submit a request to the hostname. The issue lies in this pattern is the fact that the IP address needs to be obtained twice: once for IP address verification and again for request processing. Making a DNS server that answers with a different IP for each request is quite easy. If this happens, the hostname resolves to a risky domain when the request is made, even though the IP address may be an external address and pass the security test when it is checked. This may let the SSRF to be escalated.

  Reevaluate if dynamic requests are necessary. Sometimes, defining the location of a server-side request can be done without requiring user input. To be secure, it is preferable to exclude it in this instance and create the request URLs using just static data on the server side.

• Make use of a static analysis program: A great method to detect vulnerabilities before they are released into production is to incorporate a static application security testing (SAST) tool into your devops pipeline as an extra layer of protection. When running npm tests, it is preferable to use a plugin with rules that will check your code for vulnerabilities.

What are the Real-world Examples of SSRF Attacks?

SSRF attacks have been observed in various other real-world scenarios, including the exploitation of vulnerabilities in web applications, APIs, and cloud services. The most well-known SRRF attack examples are as follows:

• Capital One: In 2019, Capital One suffered a data breach due to an SSRF attack. The attack exploited a vulnerability in the company's web application. It let an attacker access AWS credentials and steal sensitive data. Capital One Financial migrated its IT operations to the cloud and deployed a web application firewall (WAF), but failed to notice it was misconfigured. Attackers discovered this and used the WAF to send a request to an internal identity and access management (IAM) service. They relied on their knowledge of the IP address used for the IAM service by Capital One’s cloud provider. Although requests from internal network components, such as the WAF, were trusted and accepted, this service was not available to traffic sources outside of the cloud. Credentials for the WAF compute instance were sent to the attackers in response. They then discovered the contents of cloud storage resources by querying them with these credentials, and they methodically exfiltrated the data to an outside web repository.

• Atlassian Confluence: SSRF attacks have been used to exploit vulnerabilities. It leads attackers to execute code on internal servers and gain unauthorized access to sensitive data.

• SolarWinds: The SolarWinds cyber attack in 2020 involved the employment of an SSRF weakness. Even though it wasn't the main reason, it is considered that it may have helped attackers inject malicious code into the company's software updates and patches.

What is the difference between SSRF and other similar vulnerabilities?

Server-Side Request Forgery (SSRF) is a type of web security vulnerability that allows an attacker to cause a server to make requests to unintended locations. This can lead to unauthorized access to internal resources, data leakage, or even remote code execution. SSRF is different from other similar vulnerabilities such as Cross-Site Request Forgery (CSRF), Cross-Site Scripting (XSS), and Remote File Inclusion (RFI)/Local File Inclusion (LFI) in several key ways. The comparison of SSRF, CSRF, and SQL injection is given in the following table:

Vulnerability	Target	Intent	Manipulation Method
SSRF	Server	Gain unauthorized access	Malicious URL injection
CSRF	User Session	Perform unauthorized actions	Tricking user's browser to send forged requests
SQL Injection	Database	Access or manipulate data	inputs

Table 2. SSRF vs CSRF vs SQL Injection

The details of differences in these vulnerabilities are going to be discussed in the following parts of the article.

Difference between Server-Side Request Forgery (SSRF) and Cross-Site Request Forgery (CSRF)

Both CSRF and SSRF are malicious attacks on web applications that exploit weaknesses in how a web server handles URLs. Although they share similarities, they differ in their primary targets and purposes.

CSRF is also known as XSRF. It is an attack where hackers trick a user into submitting a request to a web app on which the user is authenticated. This can lead to unwanted acts on the app like changing account details or initiating transactions. Attackers exploit the trust that the app has in the user’s browser. The attack typically occurs on the client side, which is why it is often referred to as client-side request forgery.

CSRF does not provide an attacker with any access to sensitive data. The real request and answer are carried out separately. This is so even while the hacker compels the user's browser to visit the target web page. Sensitive information only reaches the target user's computer and not the attacker's. This is so even the attack causes sensitive information to be sent in response to the malicious request. By using a CSRF vulnerability, an attacker can coerce a target user into acting in their best interests. These include altering their account password to one they already know.

Conversely, SSRF attacks occur when a hacker deceives a server into sending requests to other servers or internal network resources. This can lead to unauthorized access to internal resources, data leakage, or even remote code execution. The hacker takes advantage of the server's confidence in other internal systems or in itself.

Targets and attack vectors are where CSRF and SSRF diverge most. SSRF targets the server and takes advantage of the confidence that the server has in other internal systems or itself. CSRF targets the user's browser and takes advantage of the trust that the application has in the user. Both CSRF and SSRF attacks can have serious repercussions. It's imperative to put in place the right security measures to guard against them.

Difference between Server-Side Request Forgery (SSRF) and Cross-Site Scripting (XSS)

SSRF and XSS attacks are distinct from one another even though they have certain similarities. XSS injects a command into the application that tricks a browser into performing an unwanted action. CSRF, on the other hand, manipulates the browser into making an unwanted request for the web application. SSRF tricks the app into retrieving data that it should not see.

XSS is a web security vulnerability where an attacker injects malicious scripts or queries into a vulnerable web application. These happen to be usually created in Javascript language. XSS is pretty common, and it’s one of the highest in the prevalent security issues list. It is considered to be found in around two-thirds of all applications according to the OWASP security list.

XSS attacks take advantage of web application vulnerabilities. Imagine a web page that includes user input from the URL without proper sanitization. It is possible for a hacker to craft a link that appears benign but contains malicious code. The embedded malicious code activates when a user visits this link in a regular manner. For instance, if the website doesn't sanitize scripts contained in the URL and a session cookie is present, hackers may create a script that transfers the session cookie to a server under their control. All they need is for someone to fall prey to it. The most likely possibility is that a comment box or other kind of user input on the website could pick up and store a script that looks similar. It now runs on each page load, giving the attacker access to session cookies. Here, people's trust is exploited because they might not be aware of the hidden danger. This scenario calls attention to strong security measures. The website is being tricked into executing malicious code. Attackers may be able to obtain confidential user data when they discover weaknesses in XSS. XSS can lead the attackers to change the website, inject malicious content, or redirect users to harmful sites.

Difference between Server-Side Request Forgery (SSRF) and Remote Code Execution (RCE)

RCE flaws give an attacker the ability to run any code remotely on a target device. One example was Log4j. It is a Java library used in web scripting. Various RCE vulnerabilities were discovered in Log4j in 2021 and it was letting crypto hackers and malware on some servers. Hackers may apply RCE in the following ways:

• Injection Attacks: User-provided data is used as input to a command by a variety of programs, including SQL queries. An injection attack occurs when an attacker intentionally gives input that is intentionally distorted so that a portion of it is read as a command. This gives an attacker the ability to run arbitrary code or modify the commands.

• Deserialization Attacks: Applications frequently employ serialization to condense several data points into a single string for simpler communication or transmission. The deserialization application may interpret user input that has been specially formatted within the serialized data as executable code.

• Buffer Attacks: Programs allot fixed-size memory blocks on a regular basis to hold data. An attacker could be able to create an input that writes outside of the buffer if this memory allocation is done improperly. The application may be able to execute user-provided data that has been written correctly since executable code is kept in memory.

RCE attacks are made to accomplish a number of objectives. The primary distinction between RCE and other exploits is that RCE encompasses denial of service, information disclosure, and remote code execution. Ransomware attacks and crypto mining hacks could result from it.