Server-Side Request Forgery
Description
Server-Side Request Forgery (SSRF) attacks are a type of security vulnerability wherein a malicious actor can manipulate a parameter on the web application to create or control requests from a vulnerable server. These attacks are often used by attackers to target internal systems that are inaccessible from the external network due to the use of a firewall.
The most common case is a server application which, in order to implement a feature, performs HTTPS requests to a third party server. This request may be needed to: consume an Internet API, download a package or retrieve user information via a social account (e.g. Facebook, Gravatar). An attacker might abuse the feature to perform requests to another third party or to profit from the privileges of the server in regard to the original third party system (e.g. to exfiltrate data).
In essence, SSRF attacks exploit one of the foundations of robust security, trust, by exploiting existing trust relationships to escalate attacks from applications against other back-end systems or even the server itself.
Impact
A successful SSRF attack can enable a malicious attacker to escalate and laterally move their way behind the firewall in the back-end web server without restriction, leading to the potential full compromise of confidentiality, integrity, and availability of the application.
The fallout from attacks that have successfully executed SSRF as part of their toolkit will be as extreme as the amount of data at risk. In the case of the infamous 2019 Capital One hack, the numbers speak for themselves: the compromised data included names, addresses, phone numbers, self-reported income, credit scores, and payment histories, among other personal information belonging to approximately 100 million customers in the United States (that is roughly 1/3 of the population) and 6 million customers in Canada.
As with so many issues in security, human error undoubtedly played a part in the above example as the genesis of the breach entry was a misconfigured firewall.
Scenarios
Usually, client web requests are performed through language functions that support defined classes of protocols, such as HTTP, and make their use very simple for the developer.
According to the way the vulnerable request is implemented at the server side, the attacker might be able to reach another website. An attacker can even change the protocol and, as example, use the file:// protocol, which is accepted by default in many cases, to read any file on the filesystem.
SSRF attacks remain quite powerful due to firewalls and network security; an attacker able to forge an arbitrary request through the server will benefit from the server’s physical/logical position and the active firewall rules. A network resource that is invisible and forbidden to the attacker might be available when the request is executed from the server. A common example is a management server which is hidden to the outside world but allowed from the server, as it might manage its updates or monitor its usage.
Lastly, attackers can monitor the average elapsed time for SSRF directed to open TCP ports and compare it to requests directed to closed or filtered TCP ports. By submitting a fairly small amount of requests, an attacker can map the network and discover open and closed ports that could be the target of further attacks.
Prevention
If a list of permitted URLs is known, developers should implement a hostname or IP address allow list for the application. The URLs should never be validated against a blacklist; this approach is prone to get easily circumvented using a number of well-known techniques.
Developers should disable unused URL schemas if HTTP and HTTPS are the only active protocols the application utilises to make requests.
To reduce the risk of an attacker taking advantage of response data leakage, the developer must ensure that, when sending a request to another server, the raw response is never returned as is to the client application.
When SSRF happens, the main defense in depth is to lower the trust to the server. This can usually implemented through firewall rules at the inbound end (e.g. the other server receiving the request) but it’s much harder to implement through firewall rules at the outbound end due to the nature of TCP.
Testing
Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports.
- OWASP ASVS: 5.2.6
- OWASP Testing Guide: Testing for Server-Side Request Forgery