Server-Side Request Forgery (SSRF): A Beginners Guide

Hello aspiring Ethical Hackers. In our previous blogpost, you learnt about web application hacking. In this artcle, you will learn about Server Side Request Forgery (SSRF) vulnerability, a dangerous vulnerability in web applications and websites.

Server-Side Request Forgery is one of the most misunderstood web vulnerabilities. Yet it can be incredibly dangerous. For beginners in ethical hacking, SSRF is an important concept because it shows how attackers can abuse a trusted server to access internal systems that are normally hidden from the public internet. Let’s break it down in simple terms for you.

In this article, we’ll explain you what SSRF is, how it works, types of SSRF attacks, examples, how to prevent and detect this attacks and case studies of notable attacks in real-world.

What is Server Side Request Forgery?

Server-Side Request Forgery happens when a web application fetches a URL based on user input, but fails to properly validate it. This allows an attacker to trick the server into making unintended requests. Instead of the attacker directly accessing a restricted resource, they make the server do it for them.

Think of it like this:

You’re not allowed inside a secure building. But you convince a trusted employee to go inside and bring something out for you. In SSRF, the web server is that trusted employee.

In an SSRF attack, an attacker can exploit a web application to send requests to other internal or external servers, bypassing access controls and security mechanisms.

SSRF attacks differ from other web application vulnerabilities, such as Cross-Site Scripting (XSS) or SQL Injection (SQLi), in that they do not rely on injecting malicious code into a web page. Instead, this attacks exploit the application’s ability to send requests to other servers.

How Server Side Request Forgery Attacks Work

1. The attacker sends a request to the vulnerable web application, often by manipulating a user-controlled input field such as a URL parameter.
2. The web application processes the request and sends a request to another server, typically based on the user’s input.
3. The attacker intercepts the request and modifies it to send a request to a different server, often an internal server that is not accessible from outside the network.
4. The vulnerable web application sends the unauthorized request to the attacker’s desired server, bypassing access controls and security mechanisms.

A Simple Example

Let’s see a simple example of a SSRF attack. Imagine a website that allows users to fetch profile pictures by entering an image URL:

https://example.com/fetch-image?url=https://images.com/photo.jpg

The application retrieves the image from the given URL and displays it. But what if an attacker changes the URL to something like given below.

http://localhost/admin

Now the server tries to access its own internal admin panel — something that should never be exposed to the public. Even worse, attackers might target:

http://169.254.169.254/

This special IP address is often used by cloud providers to expose instance metadata services. In environments like Amazon Web Services, this endpoint can reveal sensitive data such as:

• Temporary credentials
• Access keys
• IAM role information

If exploited successfully, SSRF can lead to full cloud account compromise.

Types of SSRF Attacks

SSRF attacks can be classified into three main categories:

1. Basic SSRF attacks,
2. Advanced SSRF attacks, and
3. Blind SSRF attacks.

Basic SSRF Attacks:

Basic SSRF attacks are the simplest form of attacks and involve manipulating user-controlled input to send unauthorized requests to other servers. These attacks can be prevented by validating and sanitizing input, limiting the scope of the request, and restricting the types of URLs that can be accessed.

Advanced SSRF Attack:

Advanced SSRF attacks are more complex and involve chaining together multiple vulnerabilities to achieve the desired result. These attacks can involve exploiting logic flaws, race conditions, or other vulnerabilities to bypass security mechanisms and gain access to sensitive information.

Blind SSRF Attack:

Blind SSRF attacks are a type of attack where the attacker does not receive a direct response from the target server. Instead, the attacker can use timing or error messages to determine whether the request was successful. Blind SSRF attacks can be more difficult to detect and prevent as the attacker is not receiving a direct response.

Why SSRF Is Dangerous?

SSRF is considered dangerous due to the following reasons.

1. Access to Internal Services:

Internal systems are often protected by firewalls and not accessible from the internet. But the vulnerable web server can access them. This might include:

• Internal APIs
• Databases
• Admin dashboards
• Microservices

The attacker uses the server as a pivot point.

2. Cloud Metadata Exposure:

In cloud environments like Microsoft Azure and Google Cloud, metadata services store sensitive configuration details. If the application allows SSRF, attackers can retrieve:

• Access tokens
• Service account credentials
• Configuration secrets

This is why SSRF is extremely common in cloud breach case studies.

3. Bypassing Firewalls:

Firewalls protect internal networks from external traffic but they usually trust internal traffic. Since the request originates from the server itself, firewall rules may not block it.

Real-world examples of SSRF Exploitation

SSRF attacks can have a wide range of consequences, from accessing sensitive information to system compromise and data exfiltration. Here are some examples of real-world SSRF attacks.

1. Yahoo Data Breach:

In 2016, Yahoo suffered a massive data breach that exposed the personal information of over 500 million users. The attack was carried out using an SSRF vulnerability that allowed the attacker to access Yahoo’s internal systems and steal the user data. The attacker used a common vulnerability in Yahoo’s image processing system that allowed users to submit URLs to be resized or cropped. By submitting a specially crafted URL that included instructions to access Yahoo’s internal systems, the attacker was able to gain access to sensitive information and cause widespread damage.

2. CapitalOne Data Breach:

In 2019, when Capital One suffered a massive data breach that exposed the personal information of over 100 million customers. The attack was carried out by exploiting an SSRF vulnerability in Capital One’s web application firewall, which allowed the attacker to access the company’s AWS server and steal sensitive information. The attacker was able to use the SSRF vulnerability to obtain AWS credentials and gain access to the server, which contained sensitive information such as names, addresses, credit scores, and Social Security numbers.

3. Shopify:

In 2018, a security researcher discovered an SSRF vulnerability in Shopify that allowed an attacker to obtain the API keys for the company’s payment gateway. By exploiting the vulnerability, the attacker was able to obtain sensitive information and perform unauthorized transactions.

4. Tesla Cloud Credential Theft:

In 2018, a researcher discovered an SSRF vulnerability in Tesla’s cloud infrastructure that allowed them to obtain access tokens for the company’s AWS account. The attacker was able to use the access tokens to launch instances in the company’s AWS account and perform other malicious actions.

5. Jenkins CI Server Compromise:

In 2017, a vulnerability in the Jenkins CI server allowed an attacker to compromise the server and gain access to sensitive information. The vulnerability was caused by an SSRF vulnerability that allowed the attacker to access internal servers.

How to Prevent SSRF?

SSRF vulnerability can be prevented by taking measures shown below.

1. Whitelist Allowed Domains:

Only allow requests to specific trusted domains.

2. Block Internal IP Ranges:

Reject requests tointernal IP addresses like,

• 127.0.0.1
• 169.254.169.254
• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

3. Disable Unnecessary Protocols:

Allow only HTTP and HTTPS protocols if needed.

4. Use Cloud Metadata Protection:

Using Cloud Metadata Protection can help in preventing this vulnerability. For example, AWS introduced IMDSv2 to reduce SSRF-based metadata theft.

5. Network Segmentation:

Limit what the web server can access internally.

How Ethical Hackers Test for SSRF?

In real-world, Ethical Hackers test for this vulnerability by,

• Modifying URL parameters
• Attempting requests to localhost
• Testing cloud metadata endpoints in lab setups
• Monitoring outbound traffic

Why Beginners should learn about this vulnerability?

SSRF teaches several important security lessons to beginners like you. They are,

• Trust boundaries matter
• Internal networks are not automatically safe
• Cloud misconfigurations amplify risk
• Input validation goes beyond forms and search boxes

It also demonstrates how modern infrastructure complexity can introduce unexpected attack paths.

Conclusion

Server-Side Request Forgery may sound technical, but at its core, it’s about abusing trust. When a server blindly trusts user-supplied URLs, attackers can manipulate that trust to access hidden systems. For beginners in ethical hacking, mastering SSRF builds strong foundational knowledge in:

• Web application security
• Cloud security
• Network architecture
• Secure design principles

And in today’s cloud-driven world, understanding SSRF isn’t optional. It’s essential.

Follow Us

• 
• 
• 
•