What is Server-Side Request Forgery (SSRF)?

One of the most dangerous things a company can do is lose the trust of its customers and stakeholders. Unfortunately, this is a common reality that occurs frequently. Since so much business is conducted online, it doesn’t take much for a data breach to occur, leading to the loss of sensitive customer data. Typically, this data is initially scanned for personally identifiable information (PII) like bank details, logins, passwords, and any other pieces of sensitive data. After that, the data is sold to the highest bidder—often to another hacker that specializes in different types of fraud. To prevent hackers and other bad actors from accessing the data of your customers and employees, businesses need to be proactive in setting up guardrails and other safety measures that keep their data secure. Often, these safety mechanisms are built around a company’s servers, which makes understanding “server-side request forgery” threats incredibly important.

We’ll show you how server-side request forgeries occur, and what your company can do to stop them in their tracks.

What is Server-Side Request Forgery (SSRF)?

Server-side request forgery (SSRF) is an exploit where a threat actor abuses the functionality of a web application on the server-side, causing it to access or manipulate information that would otherwise not be accessible to the hacker.

An SSRF attack can force a server to connect to services within the organization that would otherwise be inaccessible to non-company users. Hackers could also force the server to connect to external systems in order to exfiltrate data such as usernames and passwords.

This data can then be used to further exploit more valuable information, either by inputting it into the system directly or as the basis of an XSS attack against high-value targets within the company.

Server-Side Request Forgery Examples

There are many ways that a server-side request forgery can be used against an organization. One of the most popular instances of this attack in recent memory was perpetrated against Capital One in 2019.

An SSRF vulnerability was exploited by a hacker, allowing them to access the organization’s AWS credentials. Then, they used the application server to obtain metadata from the application itself, exfiltrating the stolen data before the organization’s security settings were even triggered.

Like with many attacks, the hackers were in and out with valuable data before the attack was even identified, much less blocked. Since SSRF attacks involve a request being made to the server, all the damage can be done on the back end without the involvement of a human being.

There are three types of SSRF attacks that can be identified based on how the server responds to the initial request.

Blind SSRF

A blind SSRF is a bit harder to track since nothing is sent from the server to the hacker. In this case, an SSRF request is made, and instead of sending back data, the server gives permission for the bad actor to make changes to the server itself. From there, the hacker can modify the website or web application, crash it (an action typically called a denial of service (DoS) attack), or take another detrimental action that disrupts the effective functioning of the company.

Since there’s nothing sent from the server to the hacker, it can be harder to spot these attacks until the damage is done.

Semi-Blind SSRF

Similar to a blind SSRF, this type of attack does not return much data, but the data it does return can be helpful for attackers to later use to plan a more in-depth attack. It could include data points like error messages or response times.

Non-Blind SSRF

Essentially, in a basic SSRF attack, the server returns data to the hacker when prompted by the initial request. This allows the hacker to walk away with this data or use it to gain entry to parts of the server that they would normally be barred from accessing.

How to Find an SSRF Vulnerability

SSRF mitigation is all about authorization verification within the secure software development lifecycle (SDLC). As such, taking the time to run significant tests will help you eliminate possible entry points once your website or application goes live.

Good code that has proper protections can stop SSRF attacks. You can use human checks and programs to run simulation tests to prevent vulnerabilities, as well as follow some of the best practices below:

• Restrict the use of network calls if they aren’t required, since they can lead to the exposure of sensitive information.
• Use an allowlist to permit access only to certain objects or locations, and/or a denylist to block all requests with unsafe or unknown parameters.
• Restrict request protocols like ftp://, gopher://, or file://

If you have concerns that there are still areas of your web applications that are open to SSRF vulnerabilities, do some testing for SSRF. By testing areas that may be open to exploitation, you can determine how to move forward with more specialized and responsive cybersecurity.

SSRF Cheat Sheet

To help protect companies from SSRF attacks, OWASP has developed a cheat sheet that can provide developers with advice on how to set up their software development lifecycle (SDLC) to close existing SSRF vulnerabilities and prevent new ones from occurring. You can find it here.