APIs are essential to modern cloud applications, but their growing complexity makes them increasingly vulnerable to threats. One noteworthy example is server-side request forgery (SSRF), which is a type of attack that exploits an application’s ability to make API calls on behalf of a user. SSRF attacks can be particularly harmful in cloud environments because they give attackers access to an application’s supporting infrastructure, such as cloud metadata services and credentials. They can also lead to costly data breaches if not detected.

The challenge in stopping SSRF attacks often comes from the inability to easily differentiate them from legitimate traffic. Understanding where SSRF attacks are most likely to occur and how to detect them is an important part of securing cloud applications and APIs.

In this post, we’ll look at common SSRF attack techniques and how to detect them using Datadog.

A primer on SSRF attacks

SSRF attacks can exploit web applications that either fail to properly validate user-supplied URLs or include vulnerable third-party libraries. Our research shows that exploitable vulnerabilities are prevalent across services—44 percent of Java services contain at least one known vulnerability, such as those found in outdated Jackson or Apache libraries.

These types of security risks increase opportunities for attackers to make requests to internal resources the applications can reach—whether that’s a cloud provider’s metadata API or a private backend service. Imagine a scenario where an attacker uses a vulnerability to force the application’s backend to query an unintended resource, such as an Amazon EC2 IMDS endpoint:

POST /products/item
{
"productApi":"http://169.254.169.254/latest/meta-data/iam/security-credentials/sample-ec2-role"
}

The application will then process the request by returning sensitive data associated with the sample-ec2-role, such as access keys and tokens. This is particularly dangerous because any permissions attached to that role are now accessible to the attacker.

To take our attack scenario a step further, if the associated EC2 instance has administrative access, then the attacker has that same level of access to the AWS environment where the instance is running. Upgrading to IMDSv2 is the recommended mitigation, but it is often not enforced across EC2 instances—on average, less than half of instances use IMDSv2. This statistic is just one example of many existing vulnerabilities that enable attackers to use SSRF attacks across modern cloud-based applications.

Detect SSRF attacks in your cloud applications

SSRF attacks can be difficult to detect since they are disguised as application requests, but there are a few signs to look out for. One good place to start is monitoring the timing and nature of an API call’s response for initial signs of malicious activity. For instance, if an API call times out consistently or suddenly takes longer than usual to process, it could mean that it has been manipulated as part of an attempt to access an unexpected resource. An error or significantly short response time could indicate that an attacker’s target endpoint or resource wasn’t available. A longer response time, on the other hand, suggests that the target was available and successfully processed the request.

In the following screenshot, you can see noticeable spikes in the number of detected attacks within a short period of time for the /login API endpoint:

Investigating these issues further can help you confirm if the API is indeed being targeted by an attacker. For example, you can look for the following usage patterns in affected API calls:

• Requests to sensitive domains and IPs (e.g., metadata.google.internal)
• User input that tampers with a URL’s structure to introduce new schemas in the request (e.g., file://, sftp://)
• Malformed URLs that attempt to bypass an application’s parsing libraries (e.g., instance.db:8000:1234/?q=example)

As previously mentioned, one common sign of SSRF activity is seeing your application execute network requests to unusual hosts, such as cloud metadata APIs. For example, in the following screenshot, you can see that an attacker supplied the https://169.254.169.254 metadata URL in the body of a POST request, which Datadog Application and API Protection (AAP) flagged as malicious.

Datadog AAP provides out-of-the-box detection rules for automatically detecting these actions. It also enables you to block the attacking IPs via the in-app web application firewall (WAF). Since Datadog AAP is designed to analyze service-to-service request traces, it can more efficiently block an attack than typical perimeter WAFs, which require constant re-tuning to mitigate attacks.

Protect your APIs from SSRF attacks

In this post, we looked at SSRF attacks and how they target cloud applications. We also walked through some practical ways that you can detect these types of attacks against your services. To mitigate SSRF attacks, OWASP provides several recommendations. For more information about using Datadog App and API Protection to detect signs of SSRF attacks, check out our documentation. If you don’t already have a Datadog account, you can sign up for a free 14-day trial.