Technical Insight

SSRF and the Cloud 101: Basics on the Latest Headline-grabbing Vulnerability

Server-side request forgery (SSRF) has been in the news recently for causing mainstream data breaches impacting hundreds of millions of consumers. These vulnerabilities make it possible for cybercriminals to trick a specific server into connecting to a different system than intended, allowing them deeper access into the targeted company’s network, cloud applications and ultimately, sensitive data. So you can see why it has organizations everywhere concerned.

In this post, we’ll explore the ins and outs of this latest headline-grabbing vulnerability, how it impacts cloud applications and how organizations can prevent it to begin with.

First, it’s important to know how SSRF itself works. SSRF exists when a web application allows a user to make arbitrary requests using the server as a proxy. Since the server is making the request, it is able to access resources that would otherwise not be publicly accessible. With this in mind, we can look at how cloud computing fits in with SSRF.

In today’s world, the amount of applications hosted on a cloud provider is growing every day. Its benefits include faster deployment times, higher application uptimes, and auto scaling, just to name a few. With the adoption of cloud computing, the need for instance configuration grew, and as a result, many cloud providers now include an application programming interface (API) within each cloud compute instance. This API facilitates information retrieval and manipulation but is only accessible locally from the running instance. This means that private keys that are stored on the instance would not typically be accessible without a user already being logged in.

Unfortunately, with SSRF, the premise that a trusted user is utilizing these APIs goes out the window. A malicious actor can use SSRF to gain valuable information about the compute instance, private keys and the resources allocated to it. It is important to note that cloud providers are not introducing vulnerabilities by including these APIs within their compute instances. Instead, this example shows how vulnerabilities can be introduced by teams who might depend too highly on cloud providers for their application security.

So how does one protect against SSRF?

Any feature that prompts the server to make a request should ensure that the values allowed are protected via a whitelist. This allows for known safe requests to be made and prevents a user from abusing the feature to reveal sensitive information. Secondly, the best practice security configurations recommended by the utilized cloud vendor should be enforced. These will usually include the steps needed to configure access based on the least privilege model among other guidelines. Lastly, incident logging and response should be in use by every cloud resource. Doing so will help prevent successful SSRF attacks.