OWASP Top 10: Server-Side Request Forgery (SSRF)

Some web applications fetch remote resources on behalf of the user. For example, a website designed to process user-provided images may allow them to provide a URL from which the application would fetch the image.

When accepting a URL from a user to make a remote request, it’s vital to validate that this URL meets expectations. Otherwise, this introduces server-side request forgery vulnerabilities (SSRF), which allow a malicious user to make malicious requests to bypass security controls.

What is the Risk?

A web application deployed within an organization’s environment may have different levels of access than an external attacker. For example, firewalls may allow requests from the web app to various internal services so that the tool can fetch data from a database or take similar actions.

SSRF vulnerabilities are dangerous because they allow an attacker to trick an application into performing requests on the attacker’s behalf. This may allow an attacker to bypass firewalls or other security controls to access sensitive data or take other actions against the business.

Examples of Attack Scenarios

SSRF vulnerabilities primarily allow an attacker to bypass access controls designed to ensure that only internal or approved devices are allowed to access a particular resource. Some ways that an attacker could abuse this type of vulnerability include the following:

ACL Bypass

An organization may have access control lists (ACLs) in place to restrict access to internal resources. For example, certain systems or applications may only be accessible from known IP addresses.

An SSRF vulnerability may allow an attacker to bypass these restrictions by having the vulnerable web application make requests on its behalf. Since these requests would originate from a company-owned IP address — the IP address of the web server hosting the vulnerable application — they would be approved, while ones originating directly from the attacker would not. This could allow the attacker to access sensitive information from within the organization’s network.

Port Scanning

Port scanning can provide useful information about an organization’s network and the various applications active on it. With enough information about running applications, an attacker may be able to identify and exploit unpatched vulnerabilities in the code.

Often, companies block port scanning at the network boundary to prevent this type of reconnaissance. However, SSRF vulnerabilities may enable an attacker to trick the vulnerable application, which is inside the protected boundary, into performing the port scan on its behalf.

Case Study: Capital One

In 2019, Capital One suffered a breach related to an SSRF vulnerability in the financial institution’s web application firewall (WAF). The WAF was assigned excessive permissions within the organization’s AWS environment and was tricked into performing requests on the attacker’s behalf to the AWS metadata service. By doing so, it generated temporary credentials that the attacker could use to access sensitive information within the AWS environment.

The attacker was a former AWS employee who accessed the data of approximately 100 million American customers and 6 million Canadians. This included highly sensitive personal information, such as Social Security Numbers (SSN), bank account numbers, credit scores, and more.

How to Remediate Server-Side Request Forgery (SSRF)

SSRF vulnerabilities have the potential to undermine an organization’s application and data security policies. Some best practices to manage these risks include:

• Least Privilege Access: An attacker may be able to abuse the privileges and access assigned to an application, and excessive permissions exacerbate this issue. All applications should be assigned the minimum privileges required for their role.
• Network Segmentation: Public-facing applications are a prime target for cyberattackers, and a vulnerability in them can place other systems at risk. These applications should be segmented from the rest of the network to minimize the damage if they are compromised by an attacker.
• Use an Allowlist: SSRF vulnerabilities are most dangerous when an attacker can provide any URL and have the application fetch that resource on their behalf. Creating an allowlist of approved resources that the user can request (specifying the schema, port, and destination) reduces the potential for misuse.
• Sanitize User Input: An attacker may attempt to use an obfuscated or malformed URL to evade an allowlist and trick the application into fetching unapproved resources on their behalf. All input should be sanitized and validated before being compared to the allowlist to limit the potential for a malicious bypass.
• Parse Responses: Returning the raw response from a remote resource may reveal sensitive information, such as error logs that could contain internal IP addresses and similar information. All data retrieved from a remote source should be parsed and sanitized before being passed on to the user.
• Disable Redirects: An attacker may be able to use redirects to evade an allowlist and visit an unapproved site. All retrievals of remote resources should disallow redirects.

How IONIX Can Help

SSRF vulnerabilities can be dangerous because they undermine security controls implemented outside of the application. If the application is trusted by firewalls and ACLs, then the attacker can use it to make the requests that they can’t make directly.

The IONIX platform helps organizations to proactively manage the security risks of SSRF and other OWASP vulnerabilities. When performing a risk assessment, it simulates the exploitation of these vulnerabilities, highlighting potential attack vectors and security gaps. To find out how IONIX can benefit your organization’s application security and offer improved control of your digital attack surface, sign up for a free demo.