All Blogs

Quick Summary: SSRF can target your crucial server resources and risk confidentiality. It is among the most critical web app vulnerabilities as per OWASP Top Ten list. Get a complete understanding of this security loophole along with ways to prevent it in this article. Keep reading for complete understanding and make prudent decisions.
Web applications are the most favorite targets for attackers, given their widespread use and exposure to the internet. There are numerous strategies used to target web applications including Server-Side Request Forgery (SSRF).
SSRF allows an attacker to manipulate your server and cause disruptions or financial damage. It has been the reason for several security breaches, including the Microsoft Exchange server hack and leak of data at Capital One.
Identifying and preventing such security incidents is the best measure to safeguard your data. It can help you uncover potential weaknesses in your web applications to thwart cyberattacks. Hence, testing web apps for security flaws with a reliable vulnerability scanner is the best bet against such threats.
Let’s dive into the article for an in-depth understanding of Server-Side Request Forgery.
Track Down and Thwart All Cyber Security Incidents Before They Spoil Your Image Do Security Test
Table of Contents
- What is SSRF?
- Example of SSRF to Understand How It Occurs in Reality
- Types of Server-Side Request Forgery Attacks
- Tactics Used for Server-Side Request Forgery Attacks
- How to Prevent Server-Side Request Forgery?
- The Bottom Line
What is SSRF?
SSRF or Server-Side Request Forgery, is among the critical web app security vulnerabilities. Due to this vulnerability, web apps insecurely (without validating the URLs provided by users) fetch resources available on the remote server.
Attackers can abuse the server functionality with this vulnerability to send a request to an arbitrary location. In some cases, the attacker can send the request to an unintended outbound location or connect to internal services in other cases. Usually, a server’s internal resources are the main target for SSRF attacks. These are protected behind firewalls but can be bypassed with this attack.
SSRF is also one of the OWASP Top 10 vulnerabilities that cause severe damage to victims. It can be used to launch various attacks like remote code execution, access restricted server resources, and data leaks.
Web applications that read data from URLs are vulnerable to this type of attack. Attackers can manipulate HTTP headers or utilize path traversal exploits to make unauthorized requests to any external URL.
Example of SSRF to Understand How It Occurs in Reality
Let’s understand how an SSRF attack unfolds with an example case here. Check the PHP code below.
<?php /** * The below condition ensures that the 'url' GET variable is set */ isset($_GET['url'])) { $url = $_GET['url']; /** * The $url variable lacks any validation checks * before making a request */ $image = fopen($url, 'rb'); header("Content-Type: image/png"); fpassthru($image); } ?>
The above web application code is vulnerable to SSRF (Server-Side Request Forgery) attack as it offers full control of the URL parameter without validation. As a result, an attacker not only can make ‘GET’ requests to an arbitrary website but also connect to the internal server resources. For instance, it can be used to access internal services on localhost.
Typically, enabled ‘mod_status’ is the default setting on an Apache server that allows an attacker to craft a request as below:
GET /?url=http://localhost/server-status HTTP/1.1
In response to the request, the attacker gets much information about the host server including the version, modules installed, and more. As a result, it further exposes the weaknesses of the server.
Besides HTTP or HTTPS schemas, the attacker may also try accessing other server resources by using “file” or other legacy schemas.
Get Rid of Cybersecurity Hurdles with an Advanced Web App Security Testing Solution Go for It
Types of Server-Side Request Forgery Attacks
Server-Side Request Forgery attacks can vary based on the characteristics of the underlying vulnerability. For instance, blind SSRF vulnerability results in an SSRF attack in which no response is obtained. Let’s check these types below.
- Blind SSRF: In this case of attack, the server doesn’t send any explicit response after an attacker makes a crafted request. It is like a shot in the dark as the server doesn’t return any specific data that can give a hint about the success or failure of the request. This type of attack focuses on performing unauthorized actions rather than unauthorized access to data. It might include deleting or altering files, modifying file permissions, changing server settings, etc.
- Semi-blind SSRF: In this case, an attacker does get some response that provides limited knowledge about the target server. It can help the attacker gain further details of the server and finetune their attack tactic.
- Full SSRF: It is also known as non-blind SSRF. In this case, the attacker can send a request and get a full response from the target server.
Tactics Used for Server-Side Request Forgery Attacks
The following tactics are used by attackers to manipulate servers and perform a successful cyberattack.
Encoded URL
URL encoding is a tactic used for SSRF. In this situation, an attacker could try to force an application to send a request to another URL that it didn’t intend to by using an encoded URL. Usually, URLs contain characters defined by ASCII. However, when any special characters or characters outside of the ASCII range need to be added, URL encoding is needed. In that case, ASCII code encoded with percent values is used in place of those characters.
IPV6 Address Exploit
If there is an application that allows users to enter a URL to fetch resources, attackers can exploit it to make unintended requests by entering an IPv6 address. For example, an attacker can enter a crafted URL like [::1]
that refers to localhost. Since the address is enclosed in square brackets, it can circumvent the input validation method. In addition, the IPv6 address may also be treated as valid by the application that results in loading localhost.
Local File Inclusion
When an application allows entering a file path in the URL and doesn’t sanitize it, it is likely to face server-side request forgery. In this case, an attacker can exploit this vulnerability by inserting a crafted URL. Let’s understand with an illustration:
An attacker attempts to access “some_dir/file”
on the server with IP 10.10.10.10. The attacker can manipulate the URL as follows:
http://testapp.com/?file=http://10.10.10.10/some_dir/file
How to Prevent Server-Side Request Forgery?
You can follow the tips below to mitigate the risks and protect your data from hacking attempts.
- Input Sanitization: Validating and sanitizing user input is a vital component of web app and API security best practices. It should be an essential part of your security strategy. Check for special characters and other user-supplied input that can be a bad code.
- Check URL Schemas: Make sure only valid URL schemas are allowed for your application. Check for unwanted URL schemas supplied by the user, such as “file://”, “ftp://”, http://, etc. Ensure strict security checks if your web app accepts other schemas.
- Have a Whitelist: You should create a whitelist for domains you access and check user input against this list to avoid bad requests.
- Employ Authentication for All Services: Ensure there is authentication for every service that runs in your network, such as Memcached, Mongo, Redis, etc.
- Conduct Security Testing: While you may look for threats on the surface, the real problem might lie deep in the system. Finding such loopholes is critical for the security of your information systems. Hence, security testing is an excellent approach. Though it’s not a silver bullet, it mitigates the risks significantly. With vulnerability assessment, you can discover hidden risks and save your critical data and resources.
- Adopt Zero Trust Architecture: Adopt a “no trust” policy for all users, whether internal or external and always authenticate before providing access to resources. It can help you save critical resources and prevent potential data breaches.
Eliminate Cyber Security Risks with 98.9% Accuracy using Advanced Threat Detection Let’s Do It
The Bottom Line
Protecting your web application and server resources can be challenging with growing numbers of threat vectors. Attackers are always looking for new kinds of vulnerabilities to attempt a data breach. However, you can win this cat race by using a sophisticated web app security scanner – ZeroThreat, which can help you detect emerging security risks.
It automates vulnerability detection and enables you to identify OWASP Top 10 security risks including SSRF and beyond. You can leverage shift left with ZeroThreat by integrating it into your SDLC to ensure secure APIs and applications from the outset.
With an AI-powered scanning engine, ZeroThreat can identify common and hard-to-detect vulnerabilities with a high rate of accuracy. It can uncover vulnerabilities with zero false positives. Get faster scanning speed and priority-based results on our DAST platform to streamline your AppSec process.
You can take a free test drive to find out its benefits.
Frequently Asked Questions
What is the main reason for SSRF threats?
Typically, many web applications require some resources to be fetched from another remote server. However, the web app doesn’t sanitize the URL to make a secure connection to a remote server, which is the root cause for server-side request forgery.
What does SSRF weakness imply?
How is SSRF different from CRSF?
What is the best method to mitigate SSRF?
How dangerous is SSRF?
How to detect SSRF?
Explore ZeroThreat
Automate security testing, save time, and avoid the pitfalls of manual work with ZeroThreat.