SSRF 101: How Server-Side Request Forgery Sneaks Past Your Web Apps

When it's time to talk attacks, it's hard to get more evil than a technique that uses victims' own systems against them. Server-side request forgery (SSRF) is one of those evil attacks, and it's one that cybersecurity pros should be able to recognize if they want to minimize the danger from within.

In an SSRF, the attacker uses the capabilities of the Web server to be tools in the attack itself. And because the Web server tends to be behind the corporate firewall, those attacks can operate without the security scrutiny that external requests and payloads would receive.

The Why
Why should you care about SSRF? Although it's a direct attack on a Web application, it enables attackers to pivot around a firewall and roll right to the back-end Web server — and from there, who knows what lateral maneuver they might make. 

It's also becoming a big problem for cloud providers — and therefore for cloud users. SSRF played an insidious part in some of the more devastating attacks in the news recently, most notably, the Capital One breach that exposed data on over 100 million Americans and 6 million Canadians. (In November, Amazon Web Services boosted its SSRF defenses in the latest version of the EC2 Instance Metadata Service.) 

The What
In an SSRF, the attacker uses carefully built URLs to manipulate the Web server's ability to reach out to resources within the organization or to resources from trusted third parties. In a typical case, the attacker will build the sort of request that might normally retrieve a product description from the database. The attacker will change the request to retrieve information from a different server or a different type of information, such as server configuration details or administration accounts.

While an SSRF attack will often be used to help an attacker move laterally through an organization, it can use the server's loopback function (a call to 127.0.0.1) to gain access to application server capabilities that would normally be hidden from the outside.

In both of these cases, the SSRF is taking advantage of the trust relationship that exists between the Web application server and the rest of the enterprise application infrastructure. Since most organizations have allowed systems within their enterprise boundaries to communicate without constant authentication, once an attacker finds a vulnerable Web server, they can move laterally to a wide variety of targets within the enterprise.

The How
There are a variety of techniques that can be used to launch an SSRF attack. Most use a URL that contains data the targeted server doesn't expect and doesn't deal with in a safe fashion. In many cases, these involve a handful of specific characters that lead the Web server astray.

In the first example of how a SSRF can begin, the URL string can begin with something other than "http" or "https." Other schema can include  "file," "dict," and "image," each indicating a specific type of resource the server expects to return, while "ftp" and "gopher" are examples of schema that specify services that will be used to return data. If an application hasn't been coded to properly whitelist only the resource and service types intended for its use, then one of the others can be the gateway to behavior the developers never intended.

The next example comes via a handful of special characters that can be embedded within URLs. These characters, like the "#" indicating a URL fragment to follow, can be the jumping off point for malicious URL excursions into resources you thought were safe. Other special characters, like "?" and "*," can provide similar points of departure through slightly different mechanisms. In all cases, though, the code that follows the special character is the malicious payload that can do digital violence to your security.

Finally, the application server itself can be attacked through URLs specifying that information be returned from 127.0.0.1 or "localhost." The malicious use of either of these locations in the URL can result in the server giving up sensitive information about itself — information that can then be used for even more powerful and pervasive attacks.

Further, as Kelly Sheridan wrote for Dark Reading: "SSRF poses a threat to cloud services due to the use of metadata API, which allows applications to access configurations, logs, credentials, and other information in the underlying cloud infrastructure. While the metadata API can only be accessed locally, an SSRF flaw makes it accessible from the Internet and could enable lateral movement and network reconnaissance."

The No
Given the danger, and the modern requirement to have Web-based application servers open to large user populations, what can be done to keep infrastructures safe? As it turns out, several safety options are available to both software developers and security professionals.

The first option is to whitelist or blacklist specific schema and resource locations. Whitelists can be quite powerful, limiting the responses to specific schema types and resource addresses. If an application requires more flexibility than a whitelist easily provides, blacklists can do the job — though they require much more thought and imagination on the part of the developer to eliminate every malicious schema and address.

Request response filters to ensure that, for example, a field expected to return a two-digit number can return only a two-digit number are powerful in their own right. They're the mirror image of input validation, in which the application filters input to make sure that only appropriate, properly formatted input is allowed.

Finally, a zero-trust approach to security, in which the various parts of the application environment must constantly revalidate to one another, can go a long way toward making sure that stray queries from malicious URLs aren't answered by servers because there will have been no application authentication between the various points.

SSRF attacks can be difficult for both human analysts and security technology to spot, and once successful can be the point of entry for malicious payloads that are both serious and long-lasting. Using application and infrastructure design to stop them before they start can help protect an organization from these URL-based bits of bad news.

Related Content: