SSRF vs. CSRF Vulnerabilities: Comparing Targets, Impact, and Mitigation Techniques

Server-side request forgery (SSRF) and cross-site request forgery (CSRF) are two types of attacks that allow attackers to make unauthorized requests, but otherwise, they are very different in nature. 

In an SSRF, an attacker manipulates the backend server of an application to make unauthorized requests to internal or external sources. On the other hand, CSRF happens in a browser, when an authenticated user is tricked into submitting an unwanted request to a web application. 

The key difference between SSRF and CSRF is the target—SSRF targets the server, while CSRF targets the user’s browser. Below, we explore these two attacks and vulnerabilities that lead to them in more detail. 

Server-Side Request Forgery (SSRF) Attack

SSRF is an attack that enables attackers to manipulate a vulnerable backend server to send malicious requests to target applications. Cybercriminals often use SSRF to target internal systems protected behind firewalls, which are inaccessible from the Internet (e.g., localhost, database interfaces and servers, and local file systems), but could be accessed from a web application belonging to the same organization. However, SSRF can also be used to send requests to external sources, such as other servers, third-party APIs, and malicious sites.

An example of the latter is when attackers force a vulnerable web application to send a request to an attacker-controlled destination. For example, threat actors can manipulate a third-party service URL that the application intends to access.

SSRF is a critical web security vulnerability, with a standalone category and CWE ID (CWE-918) that is listed in OWASP Top 10 2021 because of its severe implications and frequency. In fact, SSRF vulnerabilities have served as one of the break-in techniques in major cybersecurity incidents, including the Capital One breach and Microsoft Exchange attacks (we’ll discuss both incidents later, after explaining how SSRF works).

How SSRF Attacks Work

• Attacker identifies a vulnerability: The attacker detects that a web application has a feature that takes a URL, hostname, or IP address as user input to make a server-side request, but the application performs insufficient or no validation on the user-supplied input before making the request. 
• Attacker creates and submits the malicious request: Instead of providing a legitimate external URL, the attacker crafts a malicious URL that points to an unintended internal or external resource (e.g., the internal admin panel, the cloud metadata service, or an attacker-controlled external server). The attacker then sends this request to the vulnerable web application, such as by submitting a form or making an API call.
• The vulnerable server processes the request: Treating the attacker’s input as valid, the web application instructs its backend server to connect to the URL provided in the malicious request. Because the request originates from the trusted backend server, it can bypass network-level restrictions like firewalls that would normally block direct access from the attacker’s external IP address to internal resources.
• The vulnerable server fetches the unintended resource: The backend server connects to the internal or external resource specified by the attacker, and the resource responds to the server’s request.
• The vulnerable server forwards the response to the attacker: Depending on the response, the attackers can gather information about the internal network, access sensitive data, or confirm access to specific services, which could allow them to launch further attacks. 

SSRF Example Attack Scenarios 

The attack scenarios for SSRF are quite diverse, but here are a few examples.

Scenario #1: Image Upload With URL

A vulnerable web application allows users to provide an image URL for processing. Instead of a legitimate image, an attacker submits a URL pointing to an internal resource on the application server—perhaps a sensitive file or a backend database. 

The application server blindly follows the attacker’s input, making a request to this internal resource and may return sensitive data directly to the attacker.

Scenario #2: API Calls With Third-Party URL

If an application allows the user to specify a  URL to fetch data from a third-party service, an attacker can replace this with a URL pointing to an internal service. For example, an application might query a real-time traffic API for traffic updates, and an attacker could replace the legitimate traffic API URL with a URL like http://localhost/admin.

Scenario #3: Exploiting Weaknesses In Internal Services

Attackers can launch SSRF attacks on internal services deployed without strong authentication or with default credentials because they are assumed to be internal-only. Once these services are compromised, attackers can launch denial-of-service (DoS) and other attacks. 

Scenario #4: Accessing Cloud User Data

If a vulnerable application runs on AWS EC2, for example, an attacker can craft a request to the Instance Metadata Service (IMDS) endpoint (http://169.254.169.254/latest/user-data) to retrieve the user data.

Real-Life Examples of SSRF Attacks

2019 Capital One Breach

SSRF has played a role in several cyber attacks, including the 2019 Capital One breach where attackers exploited a misconfigured Web Application Firewall (WAF) to gain unauthorized access to the AWS IMDS. This allowed them to obtain temporary credentials for an overly permissive AWS role, which was then used to access and exfiltrate over 100 million customer records stored in S3 buckets.

Microsoft Exchange Server On-Premises Attacks

SSRF also plagued the Microsoft Exchange Server email software. Specifically, CVE-2021-26855 was an SSRF vulnerability that, according to Microsoft’s advisory, allowed unauthenticated attackers to send arbitrary HTTP requests and authenticate as the Exchange server. This SSRF vulnerability, along with other vulnerabilities, was used to achieve remote code execution and ultimately install web shells, giving attackers persistent access to affected servers. 

How to Detect SSRF Vulnerabilities

Vulnerability scanners like OWASP ZAP can detect SSRF by looking for common patterns where user-supplied input is used to construct server-side requests. If you’re using an Exposure Management solution like Attaxion, it automatically discovers all the web apps in your external attack surface and runs a vulnerability scanner like ZAP across all of them to check for SSRF and other vulnerabilities.

Start a 30-day free trial and protect your web apps from SSRF vulnerabilities now.

Cross-Site Request Forgery (CSRF or XSRF) Attack

CSRF is a web security vulnerability that enables attackers to trick authenticated users into unwittingly submitting malicious requests to a web application. It takes advantage of the trust a website places in a user’s browser and the way browsers automatically send session cookies, allowing attackers to manipulate a user’s browser into issuing a forged HTTP request. This leads to unauthorized actions from the target user’s end, without their knowledge or consent. 

How CSRF Attacks Work 

• The target user is authenticated: The victim should be logged into a trusted web application (e.g., their online banking portal, an e-commerce site, a social media platform). Upon successful authentication, the web application issues a session cookie to the victim’s browser, which confirms their identity for subsequent requests and remains active as long as the user’s session persists.
• The attacker crafts a malicious request: The attacker designs a forged HTTP request that, if executed, would perform an undesirable action on the legitimate web application (e.g., transferring money, changing an email address, or posting spam). This malicious request is then embedded within a deceptive web page, often disguised as a hidden HTML form that auto-submits, an <img> tag with the src attribute set to the malicious URL, or even a simple malicious link.
• The attacker lures the victim to a malicious site: The victim is lured—through a phishing email, a malicious advertisement, or a compromised legitimate website—to visit the attacker’s controlled malicious website.
• The victim’s browser automatically submits the forged request: When the victim’s browser loads the malicious page, the embedded forged request is automatically triggered. Because the victim is still authenticated to the legitimate web application and their session cookie for that site is stored in their browser, the browser automatically includes this valid session cookie with the forged request.
• The legitimate application processes the forged request: Since the request arrives with a valid session cookie from the authenticated victim, the application has no way to distinguish it from a genuine request initiated by the user. It therefore processes the request as if the victim willingly performed the action.

CSRF Attack Scenarios

Here are a few common scenarios illustrating how a CSRF attack might unfold.

Scenario #1: Unauthorized Bank Transfer 

An unauthorized bank transfer is a classic example of a CSRF attack. It begins when a user is already logged into their online banking portal. Unbeknownst to them, an attacker has designed a malicious webpage containing a hidden HTML form configured to automatically submit a POST request to the bank’s fund transfer endpoint. This form is pre-filled with parameters instructing the bank to send a specific amount, say $500, to an account controlled by the attacker.

When the victim is lured into visiting this malicious webpage while still logged in to their bank, their browser automatically triggers the hidden form’s submission and includes the user’s active banking session cookies with this forged POST request. The bank’s server, receiving a request that appears to come from an authenticated user and lacking sufficient anti-CSRF token validation, processes the unauthorized transfer. The victim often remains unaware until they later review their account statement and discover the illicit transaction.

Scenario #2: Unauthorized Purchases 

In this CSRF scenario, a user actively logged into an online shopping site becomes a target. An attacker crafts a malicious webpage containing hidden requests that, upon loading, force the victim’s browser to send “add to cart” commands to the e-commerce site for specific items. For instance, the attacker might target a vulnerable endpoint like add-to-cart?item=expensive_gadget&qty=1. 

In more severe cases, if the checkout process also lacks robust CSRF protection and the user has saved payment details, the attacker could even trigger an unauthorized purchase. The impact ranges from a confusingly full shopping cart to actual financial loss requiring chargebacks.

Real-Life CSRF Vulnerability Examples

2008 YouTube CSRF

In 2008, researchers found widespread CSRF vulnerabilities across nearly all user actions on YouTube. The vulnerabilities could have allowed attackers to add videos to a user’s “Favorites” or “QuickList”, subscribe the user to a channel, share videos, or flag videos as inappropriate. 

2008 ING CSRF

The ING Direct (now ING) financial institution faced a CSRF vulnerability in the same year. This flaw was severe as it could have allowed attackers to trick users into making unauthorized money transfers or changing account details. An attack exploiting the vulnerability would have involved a threat actor crafting an HTTP request (likely a POST request to a funds transfer or account modification endpoint) that, when triggered by a logged-in victim, would initiate a transaction on their behalf. Since the bank’s web application lacked sufficient CSRF protection like anti-CSRF tokens, it would have processed the request.

It’s worth noting that the vulnerabilities described above had already been addressed by the respective companies. 

How to Detect CSRF

As with SSRF, vulnerability scanners are effective tools for detecting CSRF. A good scanner, such as OWASP ZAP (which specifically includes CSRF detection capabilities), can detect the absence of anti-CSRF tokens, inspect cookie attributes, and analyze if there is origin and referrer header validation.

Attaxion can automate scanning for CSRF vulnerabilities across your entire external attack surface.

Key Browser Improvements That Help Mitigate CSRF

While CSRF once posed a significant threat, its prevalence has diminished in recent years due to improvements in modern web browser security. The primary mitigating factor stems from the widespread adoption and enhanced default behavior of the SameSite cookie attribute, a robust mechanism for developers to control when a browser sends cookies with cross-origin requests. It offers three distinct settings:

• Strict: Cookies are only sent in a first-party context, preventing them from being included in any cross-site requests.
• Lax: Cookies are allowed for top-level navigations (like a user clicking a direct link to your site) but are blocked for most other cross-site requests.
• None: Cookies are permitted to be sent with all requests as long as they are marked as “Secure” and can only be sent over HTTPS.

Since the SameSite policy prevents the cookie from being sent, the attacker’s forged request arrives unauthenticated and the attack fails. 

Modern browsers have shifted their default SameSite behavior around 2020. Previously, if no SameSite attribute was explicitly set by a developer, browsers would implicitly treat cookies as SameSite=None, sending them with all requests by default. Now, however, major browsers like Chrome, Edge, and Firefox default to SameSite=Lax for cookies if no explicit setting is provided.

Conclusion

As in all things in cybersecurity, threats to web security evolve. We’re seeing a shift in the prominence of certain vulnerabilities—SSRF is becoming more prominent with its presence in the OWASP TOP10, while CSRF is much less of a problem than it was before, due to security enhancements in modern browsers.

However, it’s still important to detect and mitigate both types of vulnerabilities because even with browser-level protections, misconfigurations or specific application logic can still leave systems exposed. Therefore, it’s crucial to continuously monitor web applications using automated tools like Attaxion. 

Inventory and scan all your web apps to find SSRF and CSRF vulnerabilities with Attaxion. Start a free 30-day trial today.