Published on
The new #10 on the OWASP Top 10 2021 list is Server-Side Request Forgery (SSRF).
We find this interesting – and worth diving into – especially given the broad categories that make up the rest of the list.
SSRF is also one of only two categories not selected because of metric data. (The other being Security Logging and Monitoring Failures.) It landed on the list solely based on feedback from a survey of security professionals who ranked it as a top concern for application security.
Why does the appsec community at large find SSRF such a threat to code security? Let's look at what makes SSRF so unique and how you can code against it.
The SSRF Attack
To execute a Server-Side Request Forgery (SSRF) attack, the attacker abuses the functionality on the server to read or update internal resources. SSRF occurs when a web application fails to validate user input when fetching a resource. The attack can then force the application to send requests to access unintended resources, often bypassing security controls. A Server-Side Forgery Request vulnerability can lead to the theft and manipulation of data or even the exposure of a company's network topography.
The vulnerable application will often have functionality for publishing, reading, or importing data using a URL that a user can modify. The attacker takes advantage of this functionality by manipulating the URL or providing an entirely new URL. The code on the server will then read or submit the URL allowing the attacker to read server data, connect to internal services, or send post requests to private internal services.
Why Trust Relationships Are Untrustworthy
SSRF attacks happen when a trust relationship in a vulnerable application allows access to internal systems, sensitive data, or even app functionality. The trust relationship occurs when an application server interacts with private backend systems not intended for access by users. The accessible systems most likely use non-routable private IP addresses or are restricted to specific hosts, which assumes that the network topology protects them. Unfortunately, the result is a lack of sophisticated controls, thus opening the application to an SSRF vulnerability.
These examples illustrate how this manifests:
- A system handles a request from the local network differently from ordinary requests, bypassing validation checks.
- An application grants admin access to any user coming from a local machine without authentication.
- The admin interface lacks authentication controls and is considered hidden because it listens on a different port than the main application.
- A separate machine from the server conducts access control allowing for authentication bypass.
The central theme here is – never assume anything when it comes to code security. Trust relationships exist because an engineer doesn't implement proper security controls because they incorrectly assume attackers can't attack from an already trusted location.
The Trust Relationship Attack Surface
Attacks Against the localhost
If the local machine does not validate requests from the localhost or executes them with elevated privilege, the server becomes an attack target. The attacker convinces the application to make an HTTP request back to the hosting server via its loopback network interface. Frequently this involves the attacker supplying a URL with a hostname like 127.0.0.1 or localhost And – just like that – the attacker takes advantage of the trust relationship the system has with its internal requests.
Attacks Against Other Backend Systems
Similar to the attack against the server itself, when developers assume that network topology is protecting internal systems, we often see weak server security controls configurations for interactions on the local network. Attackers take advantage of backend systems that contain sensitive functionality and lack authentication mechanisms for anyone accessing them from the local network.
Attacks Against 3rd Party Systems
When a company does not adequately protect its systems, an attacker can hijack them to launch attacks against a 3rd party. This attack uses the trust relationship between the vulnerable company and a customer or vendor to access private resources. An attacker can also launch attacks using the vulnerable server as a pivot point, making the victim company appear to be the source of the attack.
Capital One SSRF Incident
The most famous SSRF attack happened in July of 2019 against Capital One. SSRF was used to retrieve AWS credentials that attackers used to steal over 100 million Capital One customers' personal information. Hiding behind a VPN and TOR Browser, the attacker executed an SSRF query that the server relayed to the backend AWS server because of a misconfigured WAF. The attacker then retrieved a temporary credential from the EC2 Metadata Service and ran the" ls" command to retrieve the list of AWS S3 Buckets of compromised Capital One accounts. The result? The malicious actors copied, allowing nearly 30 GB of Capital One credit application data.
Mitigations
As is the case with any training, learning how an attack works arms you and your teams with the ability to protect your applications, systems, and data from attackers. By initiating a few baseline SSRF security practices, engineers and development teams can protect data and further secure their code.
Removing trust relationships will reduce your potential SSRF attack surface. Use parameterization properly and implement a zero-trust architecture that requires the various parts of the application environment to always revalidate one another. Develop a safe list of the allowed domains, resources, and protocols for fetching resources – and enforce its use. Next, perform safe-list input validation on all inputs. Whenever possible, do not accept user input in functions that control where the webserver can fetch resources. If your application must accept such user inputs, validate.
Here at Security Journey, we believe SSRF deserves its place on the OWASP Top 10 2021 list. Its negative impact, combined with the pervasiveness of the vulnerabilities and trust relationships that allow for this exploit, make it a real threat to application security. While the metrics aren't as alarming as others on this list, SSRF has the potential to be the next supply chain-type threat without some defense-in-depth strategies.
But - the developer community has an opportunity to understand and prevent it. And here's the critical takeaway: Organizations significantly reduce the risk and impact of an SSRF attack when they implement reasonable security controls that authenticate users/machines/applications at multiple levels when accessing secure data.
