Server-Side Request Forgery (SSRF) is a type of attack that allows an adversary to make arbitrary outbound requests from a server. In some cases, an attacker can use SSRF to pivot throughout corporate networks, exploit otherwise unreachable internal systems, or query metadata endpoints to extract secrets. The severity of SSRF can vary from informational to critical depending on some factors. the visibility of the response and the nature of assets that can be reached will help determine the severity of a given SSRF defect.
In this lesson, you will learn how SSRF vulnerabilities work and how to protect your applications against them. We will begin by exploiting an SSRF vulnerability in a simple application. Then we will analyze the vulnerable code and explore some options for remediation and prevention.
Ready to learn? Buckle your seat belts, put on your hacker's hat, and let's get started!
Capitol One suffered a data breach that exposed 140,000 Social Security Numbers, 80,000 bank account numbers, and 1 million social insurance numbers. The initial attack vector was an SSRF exploit that exposed AWS credential keys; this is the exact technique that we will be covering in the interactive example below. You can read more about the Capitol One attack here.
A well renowned serial entrepreneur and startup mogul known only as "Jane" has decided to build the next Facebook. She decided to call the new social network "Meetr" because it allows you to meet new friends and because "Meta" was already taken. Meetr is only in its early stages but Jane is extremely well connected. She has a meeting tomorrow morning with some potential investors, and insists the Meetr MVP be fully functional.
You have been called in last minute for an extremely lucrative five day contract to bolster the existing dev team’s efforts. Your task is to build the ability to add profile pictures to Meetr profile. You decided that instead of just allowing the upload of profile pictures, it would be awesome to use any image on the internet by just providing a URL.
When a user sends a request with image URL, the server will request the provided image URL, return the image back to the user, and then update the profile image. Let's take a closer look at what might be possible by exploiting this SSRF vulnerability.
Firstly, we can access the web server from the machine that it is already originating from by specifying 127.0.0.1 or localhost in the URL field.
Firstly, let's recap what took place in the interactive example above.
As an attacker, we were able to determine that our URL input was being requested by the server, and we could see the response body.
We used this "feature" to pivot into the internal network and gain access to an administrative portal that would otherwise be inaccessible.
We then accessed AWS credentials by querying the AWS metadata endpoint.
And now we will have a look at this example in more detail by going through the server-side code.
A vulnerable internet-facing application can be utilized to pivot into an internal network. This is useful for attackers wishing to gain an in-depth understanding of a target's internal network.
The ability to send HTTP requests on the internal network can sometimes be more sinister than just enumeration though. There are many full-blown RCE vulnerabilities that can be exploited with a single HTTP request. One such example is in Atlassian Confluence, remote code injection (RCE) via Object-Graph Navigation Language (OGNL) (OGNL) Injection (CVE-2021-26084). This attack would result in the ability to execute code on an internal confluence server, the attack vector would look something like this:
As demonstrated in the examples above, SSRF can be anywhere from harmless to catastrophic. This depends on a number of factors like the visibility of the response and which internal hosts are accessible.
At its absolute worst, SSRF vulnerabilities could result in:
For the first time ever, OWASP has included SSRF on the OWASP top 10 list for 2021. There was an interesting note in the OWASP draft which stated "this category represents the scenario where the industry professionals are telling us this is important, even though it's not illustrated in the data at this time". It's difficult to know whether the data is just skewed because SSRF is difficult to detect, or whether SSRF is actually rare, although SSRF is quite a common bug discovered in bug bounty programs.
If it is necessary to accept dynamic input as part of the request, ensure that only external hosts are allowed to be defined. For example, you may allow requests to
220.127.116.11 but not
There are some gotchas with this method:
In some cases, it is simply not necessary to take user input to define the location of a server-side request. In this case, it is better to leave it out to be on the safe side and generate the request URLs purely with static values on the server side.
If the hosts that need to be accessed are a finite set, implement a whitelist. When a user sends a request, check that the URL or domain from that request corresponds to one in the whitelist, if it doesn't, drop the request.
The plugin contains rules that will test your code for vulnerabilities when you run
npm test. It's important to note that linters like this will not catch everything. But they are a good sanity check, and the more layers of checks we have the less likely you are to introduce vulnerabilities.
To learn more about SSRF, check out some other great content produced by Snyk:
If you want to see a real life example of SSRF, watch this video about Harbor open source registry SSRF issue.
Or have a look at an example of how to obtain AWS credentials via SSRF exploit.
If you are interested in exploring other SSRF exploitation methods, this is an excellent blog post by Assetnote that outlines a bunch of exploits that can be delivered with a single HTTP request, meaning that they might be utilised to exploit a system within the local network, by pivoting through a SSRF vulnerability.
You have taken your first step into learning what SSRF is, how it works, what the impacts are, and how to protect your own applications. We hope that you will apply this knowledge to make your applications safer. We'd really appreciate it if you could take a minute to rate how valuable this lesson was for you and provide feedback to help us improve! Also, make sure to check out our lessons on other common vulnerabilities.