Server-Side Request Forgery (SSRF) Attacks: The Ultimate Guide

Several significant cybersecurity breaches in recent years, including Capital One and Microsoft Exchange, involved server-side request forgery (SSRF) as a penetration method. These exploits can give attackers access to your organization’s most sensitive data.

This guide will help you understand the basics of SSRF attacks, how they work, and how to prevent them.

What is a Server-Side Request Forgery (SSRF) Attack Anyway?

In simple terms, server-side request forgery (SSRF) attacks trick servers into making unauthorized requests. As the name implies, these attacks use requests that have been forged by a hacker or user with malicious intent.

With a forged request, the attacker can target applications with data imports from a URL or read sensitive data from a URL. The attackers can also manipulate the URLs by replacing them with something malicious or by changing the URL path.

These attacks are typically used to access private data or internal services that aren’t supposed to be public. Once the attacker has modified a URL, they can access private data from HTTP-enabled databases and server configurations. 

How Server-Side Request Forgery (SSRF) Attacks Work

Any time someone clicks on a link or performs an action on the web, requests are made to a server. Anyone browsing the web has access to public files that are visible in public_html folders. 

But those same servers typically contain private databases and folders as well. Access to what’s in these files is usually restricted to server admins or users with privileged access. 

If an attacker can change the URL parameters to a local host, they might be able to view all of the local resources on a server. This makes the server exploitable to server-side request forgery. 

Once an attacker gains control of the server-side request destination, they can perform a wide range of malicious actions. Examples include:

• Bypass the IP whitelists
• Bypass authentication services
• Modify the trust relationship between servers and other systems
• Read and access private web resources and assets
• Run port scans for internal networks connected to the exploited server
• Interact with APIs from the server
• Access the IP addresses of servers running from a reverse proxy

The OWASP (Open Web Application Security Project) is a nonprofit organization with the goal of improving cybersecurity through open source projects. The foundation provides tools, resources, education, training, and networking opportunities for developers and security experts. 

Every year, OWASP releases a list of the top ten security vulnerabilities based on data, community surveys, testing, and other factors. In 2021, server-side request forgery attacks made the list for the first time ever as their own category. 

OWASP’s reasoning for adding SSRF to the list is based on above-average ratings for “impact and exploit potential”. In short, the community believes that SSRF can cause significant problems for organizations that fall victim to these attacks. 

SSRF Attacks vs. CSRF Attacks

SSRF attacks are commonly associated with cross-site request forgery (CSRF) attacks. But SSRF is a bigger threat to organizations and databases. 

That’s because CSRF attacks hijack a single user’s web browser. From there, the attacker can perform unauthorized actions on behalf of the hijacked user. This can be concerning if a user with administrative privileges is attacked, but the hijacker’s actions are limited to the individual user’s access.

But SSRF attacks aren’t limited to a specific user. These attacks target the server without the involvement of a user’s account privileges or web browser. Attackers can simply instruct servers to perform malicious actions through malicious HTTP requests.

Risks of SSRF Attacks

Here’s a quick overview of the potential damage that can be caused through server-side request forgery:

• Leaked Data — Cybercriminals can retrieve customer information or other sensitive data stored in databases or application servers. 
• Port Scanning and XSPA — Using metadata like response times, attackers can determine whether or not a server request was successful. If they can pinpoint the host and port, attackers can perform port scans on the application’s server through a cross-site port attack (XSPA). This could also allow them to initiate a protocol smuggling attack.
• Denial of Service (DOS) — Internal server requests typically have less traffic compared to requests coming from public-facing servers, which means the configuration of these servers won’t have the same bandwidth as public-facing ones. Attackers can use SSRF to overwhelm internal servers with traffic that surpasses bandwidth limitations, resulting in an internal DoS. 
• Reconnaissance — Hackers can use SSRF attacks to gather information about internal networks. Once they have access to servers, they can use what they’ve learned to compromise other servers on the network. 
• Remote Code Execution (RCE) — If an attacker can control a URL without restrictions, they can exploit other services that have been interfaced through HTTP queries. This gives hackers the ability to remotely execute code to core servers, which could have troubling results. 

Let’s take a closer look at different types of SSRF attacks and examples.

Example #1: Basic Server-Side Request Forgery (Non-Blind)

Web applications running on a server can access different files in a vulnerable environment. The basic foundation of SSRF is the ability to trick a publicly accessible web server, allowing the attacker to access sensitive files on the server or other connected servers that would normally be restricted.

Let’s say you have an ecommerce website using more than one server, called buy.example.com.

A public consumer can visit this website, browse for products, and make purchases. Maybe the exact product details are coming from a different server, which a public user can’t access. For this example, we’ll assume that the server powering your website has direct access to the other server with the product details. 

When a user clicks on a product, the primary server makes a request to the other server, directing the user to another URL that includes the product string. 

If buy.example.com isn’t properly secure, an attacker can use your primary server as a middleman to access restricted files from the other server. 

Depending on the hacker’s end goal, they can modify this URL to an internal IP, localhost with custom port numbers, and more. 

This hypothetical scenario using an ecommerce shop is a simple example of non-blind SSRF. 

In this case, attackers leverage visible data returned by a server to make malicious requests, access hidden files, and spy on system ports.  

Example #2: Blind Server-Side Request Forgery

Blind SSRF attacks aren’t designed to return specific data. Instead, these attacks are used to perform unauthorized actions on the back end of a compromised server. 

Once they have access, the attacker could modify files, delete files, alter permissions, and more. 

We’ll continue using the ecommerce scenario above. With blind SSRF, an attacker can modify the buy.example.com URL to another URL. 

Let’s say the modified URL looks something like this: buy.example.com/?url=http//:largeimages.com/-large-image-file.jpg/

This type of request could tell the server to fetch an unusually large file from another server. This request could potentially cause the server to crash, creating a DoS (denial of service). 

These attacks are “blind” because the goal isn’t to retrieve specific data from the server. Instead, the attacker’s goal is to perform a malicious action from the server, causing a detrimental result. 

How to Get Started With Server-Side Request Forgery (SSRF) Attack Prevention

Now that you understand how SSRF works, it’s time to make sure you protect your servers. Follow the steps below to prevent SSRF vulnerabilities from being exploited:

Step 1: Identify Server-Side Forgery Vulnerabilities 

The first thing you need to do is assess your weak points. Where could an attacker exploit your servers through a forgery attack?

You’ll want to limit your applications from blindly trusting inputs. Your apps should never assume that a request is coming from a trusted source. 

Set up your system to only work with a few hand-picked protocols, like HTTP and HTTPS requests. The protocols should only be applicable to the primary needs and purpose of the application. 

You should also limit unnecessary requests and communication between multiple servers. For example, refer back to the scenario we discussed earlier for buy.example.com that used another server for product information. Rather than using a URL string that directly accesses that server, you can set up a URL parameter so the information from an internal server never needs to go through the client side. 

The website could fetch the product ID using an address that’s hard-coded on the back end of your system. Then you can ensure that the parameters have been sanitized and the URL hasn’t been compromised. 

Step 2: Test Your SSRF Vulnerabilities

Once you’ve identified weak points, you can run tests on your servers and applications to take this initiative a step further. 

A common approach for this is the manual review of your code. During this process, you’ll need to verify that URL inputs get validated before performing an action. You should do this for all of your web applications. 

Let’s say you want to delete a user in a web app as a test. For this to happen, the app needs to request data from the server. Once you submit a request, you should inspect the HTML code to see what’s being displayed when you delete a user. 

If you see the names of administrative accounts associated with the action, it’s a sign of a potential vulnerability, especially if the admin name is attached to a URL for the deletion request. An attacker could use this information to manipulate the URL, tricking a server into assuming a request came from an admin. 

You might encounter some errors during the process. That’s ok. Errors can be helpful in identifying whether specific ports are open or closed, which will ultimately help you figure out which ones to use when you’re testing vulnerabilities. 

Step 3: Create a Whitelist and DNS Resolution

Next, you should whitelist IP addresses and DNS names that a web application needs to access. With this approach, all other requests will be denied if they’re not coming from a whitelisted IP. 

For some scenarios, the whitelist approach isn’t a viable option at scale. So you could also try a blacklist approach. For example, you could blacklist private IPs that aren’t routable. 

At a minimum, you should disable HTTP redirections and block all direct usage of user inputs. 

Segmenting your resources and limiting communication between servers can also reduce the impact of an SSRF attack if there’s a breach.

Step 4: Deploy a Web Application Firewall (WAF)

Web application firewalls are a crucial line of defense against SSRF attacks. In addition to SSRF attack prevention, they can also help prevent other application-layer attacks. 

Look for a system that has advanced cybersecurity tools. Ideally, you’ll want a WAF with features like:

• API Security — Automatically protect API endpoints when they’re published, protecting those apps from being exploited.
• Attack Analytics — Provides you with full visibility into attack patterns and attack prevention. This can help you detect vulnerabilities and harden weak points. 
• Runtime Application Self-Protection (RASP) — This helps you prevent injections and attacks from external sources. It also reduces the log of exploitable vulnerabilities. 
• DDoS Prevention Tools — Block traffic from attackers to secure both cloud and on-premises assets. Make sure the tool supports your hosting environment. 

These additional features will help with your overall approach to breach prevention. 

Step 5 — Have a Mitigation and Response Plan

SSRF prevention is obviously the priority here. But you should also have a plan in place with a blueprint of steps if an attack occurs. 

First, you need some type of detection tool. Manual detection is probably unrealistic at scale for most organizations.

Lots of security software out there offers AI tools that can detect forged requests to a server. To ensure sensitive data and information doesn’t reach the attacker, you need to make sure that the server won’t transfer anything to the client side. 

You can temporarily disable URLs that were used in the attack. As a long-term solution, you should also disable all of your unused URL schemas.