If URLs supplied through client-side web applications aren’t rigorously validated, they can be used to force vulnerable server-side applications into accessing unauthorized data - or even sensitive, internal network resources - on behalf of a cybercriminal. In such cases, the database or backend server processing the request might interpret the malicious URL as though it originated from inside of the application’s trusted network, enabling the request to bypass internal security policies and retrieve resources without needing any permissions. Referred to as Server-Side Request Forgery (SSRF), this attack vector can lead to a variety of extremely negative outcomes, including anything from large-scale data exfiltration to Denial-of-Service attacks.

How do SSRF Attacks Work?

Once a cybercriminal identifies an SSRF vulnerability, they can exploit it by submitting a modified HTTP request (containing a malicious URL) through a client-side web application. This URL contains parameters that specify which server resources the attacker wants to gain access to. The vulnerable server-side application believes it can trust this URL’s request parameters because it appears to originate from within the application’s trusted network, rather than from the client-side browser it really originated from.

If the attacker’s goal is to exploit the web application server, the malicious URL will often contain a common local hostname followed by a specific path to the attacker’s desired resources. This can allow the attacker to circumvent normal authentication protocols and access resources directly from the application server, retrieving sensitive details which are only intended for permissioned internal or external users. Application server databases with REST interfaces (NoSQL databases), for example, can be forced to submit data to the malicious URL, thereby unintentionally exfiltrating sensitive data.

If the goal of the attack is to exploit internal-facing backend servers adjacent to the application server (i.e., those which don’t contain any resources intended for external users whatsoever), the attacker can formulate malicious URLs which call out those adjacent server IP addresses and mimic internal admin controls. Vulnerable backend servers are often entirely unprotected against requests which appear to originate from within the “secure” network perimeter, and as a result, they can be forced into sharing administrative permissions and other sensitive internal information in response to the URL’s request parameters. This information can be used to carry out subsequent attacks against the vulnerable network, and once compromised, this network can in turn be used to carry out attacks against separate external networks.

How can SSRF Attacks be Prevented?

Mitigating SSRF attacks starts with performing an exhaustive review of internal and external network security architecture. Organizations need to ensure client-side inputs are validated, and they need to make sure URL requests can only be made to necessary network resources. It’s important to extensively compartmentalize internal and external resources in a network so that internal administrative controls don’t implicitly trust requests from server-side web applications.

Detecting SSRF Threats with Cloudmersive

Using the SSRF detection iteration of the Cloudmersive Security API, organizations can detect SSRF threats from input URL strings and learn the level of threat (low, medium, or high) associated with that input URL. If, for example, a URL containing the common SSRF attack parameters “localhost/admin” were entered, the API response would return a “CleanURL: False” response with a “ThreatLevel: High” description. This response allows organizations to prevent SSRF attacks and simultaneously log data on those attacks to better understand threats to their network.

For more information on Cloudmersive Security APIs, please do not hesitate to reach out to a member of our sales team.