Server-Side Request Forgery, often shortened to SSRF, is a broad vulnerability class that typically includes coercing a server into making network connections. SSRF commonly, but not always, involves the victim server issuing HTTP(s) requests. The impact can vary greatly, ranging from sensitive information disclosure, to remote code execution or authorization bypasses. The impact is always very contextual. For example, an SSRF vulnerability in software running on AWS EC2 may lead to instance credentials being disclosed via the instance metadata site (more on this later), while the same vulnerability may have little to no security impact if it is running on a temporary Digital Ocean droplet. Any endpoint that allows users to enter hostnames, URIs, or ports is potentially vulnerable, and should always be checked for SSRF exploit scenarios.
Types
Before discussing the impact of SSRF, it is important to acknowledge the different types of SSRF. The impact of the vulnerability can greatly depend on the type of SSRF vulnerability.
Blind
Blind SSRF occurs when you never get any information about a target service from the initial request. Typically, an attacker will provide a URL, but data from this URL will never be returned to the attacker. To confirm a vulnerability in this case, an attacker must use Burp Collaborator, DNSbin, or a similar tool. These tools can confirm that a server is vulnerable by forcing it to make DNS or HTTP requests to an attacker-controlled server. Blind SSRF is typically easy to validate, but difficult to exploit.
Semi-Blind
Semi-blind SSRF, similarly to blind SSRF, does not return all details about a resulting request, however, some data is exposed. This could be partial data or error messages that give the attacker more information. Sometimes metadata about a request, such as response times, can also be considered semi-blind as they allow an attacker to validate if a request succeeds. Semi-blind SSRF is often enough to validate the vulnerability, but not always enough to extract sensitive data.
Non-Blind
Non-Blind SSRF is typically the most critical issue. In these scenarios, data from an arbitrary URI can be fetched from an internal service and will be returned to the attacker.
Impact
Sensitive Data Exposure
One of the most common examples of a SSRF attack is retrieving Amazon EC2 instance credentials. If an IAM Role is assigned to an EC2 instance, the temporary credentials can be retrieved by making a request to http://169.254.169.254/latest/meta-data/iam/security-credentials/{role-name}. The impact of this can be very high depending on the access given to that IAM Role. For application servers, this often means that, at a minimum, an attacker will be able to retrieve customer data. If excessive permissions are given to the IAM Role, such as Amazon CodeDeploy access or AWS Systems Manager, then remote code execution can potentially be obtained on EC2 instances within the victim’s AWS account.
Unauthenticated Requests
The classic SSRF vulnerabilities will typically allow GET requests to localhost and network adjacent hosts. Insecure management interfaces or other APIs may exist on internal networks, and an outside attacker may be able to exploit them using the SSRF vulnerability. This is especially true for localhost in many cases, as no authentication may be required from localhost requests. Occasionally, locally running web applications will allow unauthenticated requests from localhost as well.
Port Scans or Cross Site Port Attack (XSPA)
Sometimes, no data is returned from a SSRF attack. However, based on response times or other metadata, an attacker can gauge whether a request was successful. If an attacker can specify a host and a port, they can potentially port scan the application server’s network simply by observing this metadata in what is known as a Cross Site Port Attack (XSPA). In the case of response times, a baseline failed request can be made, as the timeout for a network connection is typically the same no matter the port or host. Successful requests will often be significantly shorter than this baseline, and sometimes longer if the connection made is not closed by one of the parties. By doing this, an attacker can fingerprint the services running on the network, and sometimes launch protocol smuggling attacks.
Protocol Smuggling
A related vulnerability to SSRF is protocol smuggling. Depending on data being sent as a result of an SSRF vulnerability, an attacker can intentionally send a request to a port that doesn’t host the intended service. An example might be that an application sends an HTTP request to an attacker controlled host and port. If they attacker can control the body of this HTTP request, they can send it to another plaintext service, such as FTP or SMTP. Depending on how the receiving server handles errors, it may ignore the initially malformed HTTP data, and accept the correctly formatted data in the rest of the request. This would allow an attacker to interact with other services behind network firewalls.
Exploitation
A variety of techniques can be used to exploit SSRF vulnerabilities. These range from simply providing parameters in the correct spots to exploiting the way that a server processes certain data. It is not always obvious that an SSRF vulnerability is present, and sometimes exploitation requires taking advantage of existing workflows in ways the developer did not intend.
Server-Side Rendering
One of the commonly missed ways to achieve SSRF is through rendering of customer-controlled data. This can be a number of things, ranging from images to websites. There a variety of reasons that this functionality may be included into an application, such as rendering smart views for customers, or converting data into a different format. Below are just a few of the many ways SSRF can be achieved through rendering client-controlled data.
SVG Images
SVG images are XML documents. Normally these images are interpreted and rendered by clients. Occasionally, applications implement a feature where these are rendered server side and are provided to clients in the from a of a PNG or JPEG. Often, this process will use standardized libraries to do the conversion. Unfortunately, many of these libraries support dangerous SVG features that can lead to SSRF vulnerabilities. This is because SVG images support embedded links. If the rendering machine is in an internal network or DMZ, it can potentially make GET requests to adjacent hosts. If an attacker knows the URI of a sensitive image, this can also be retrieved.
Open Graph Tags
Open Graph tags, or og tags, are meta tags embedded in an HTML document. These typically indicate to a requesting service or user how a smart view can be generated. For example, if you type a link in your favorite social media or messaging app, often times a preview of the site with an image, description, and title are shown. While the title and description are straight forward, the image is often a URI that is retrieved by the server. If a customer can tell an application what pages to render a smart view of, an SSRF vulnerability can potentially be introduced.
PDF Rendering
Many online tools based in the cloud allow you to include external sites, data, or images. Sometimes the application will make your browser do the work of fetching these resources, other times, the application might do it, which in itself can be an issue. Regardless, these types of products often offer the ability to export to PDF. Sometimes, these are rendered by the server, so even if in normal flow of the application your browser fetches these resources, as rendering a PDF may force the server to fetch them. This can potentially lead to SSRF vulnerabilities.
Proxy
Sometimes, a web application will act as a proxy for your request, A URI parameter may be used to tell the server where to make the request to. One example where this is used, is to add a credential header to the initial request. If no verification is done, this can lead to severe SSRF vulnerabilities. This is because in this scenario, all data is typically returned. If an attacker specifies their own server as the URI parameter, the application may leak the credential header to the attacker as well.
XXE
If an XML External Entity (XXE) vulnerability is present, it can be used to perform SSRF attacks. In a typical XXE attack, you provide the URL of the external entity you want to include. This can instead be a URL of a vulnerable internal server. This can also sometimes be used to steal NTLM hashes if the victim machine is running Windows. For example, if an attacker emulates a network file share and specifies a network location they control as the external entity, servers will utilize hashes to authenticate to the attacker-controlled network file share unless mitigations have been put in place.
Vendor Software
There have been many examples of SSRF vulnerabilities in popular web application software that can lead to SSRF. Jira for example, had an SSRF vulnerability that was exploitable by remote attackers. Some versions of ColdFusion by default have an XSPA/SSRF vulnerability that can be utilized by remote attackers unless the hardening guide is followed.
Mitigations
Mitigating SSRF vulnerabilities can be difficult as these issues can originate at the application level, system level or third-party library level. While validation can always be put in place for functionality with obvious SSRF potential, it’s easy to miss those that are less obvious. For these reasons, the best solution is to use a variety of mitigations.
Proxies
When an application makes requests on behalf of users, using an external proxy can be a good idea. This does not necessarily have to be a third party but should be an isolated server without access to any internal network resources. Ideally, this should be set up with a cloud provider in a different account then where critical resources live.
Offload
Certain server-side rendering workflows can be offloaded to third parties. For example, a third-party service might offer PDF rendering of your customer’s data. Similarly, other services may handle images and other dangerous-to-render files for you, reducing the risk of SSRF. This may come with other risks if the data your sending to others is sensitive.
Firewalls and Network Segmentation
Stateful firewall rules can drastically reduce the risk associated with SSRF vulnerabilities. Most application servers don’t need the ability to connect to every internal network service. This is especially true in the cloud. Using proper network segmentation and applying the principle of least privilege to outbound connections from application servers can reduce the severity of SSRF vulnerabilities. Unfortunately, it’s not always common to see this level of segmentation, as it can be tedious to implement, and decreases the overall usability of the network. At the very least, its recommended to try to prevent access to critical servers or legacy servers with known issues.
Validation
Applications that accept URLs by design should do validation to determine that they are valid and will not allow harmful requests. It’s very easy to make mistakes in doing this. If relying solely on this, it’s recommended to validate the checks put in place against current SSRF bypass techniques.
Third Party Package Review
Third party packages that are called from applications should be reviewed. For example, if image rendering software accepts JPEG and PNG, and customer files are passed to that, make sure it also does not support features that can introduce SSRF vulnerabilities. In this case, maybe the library also might support SVG files. If an issue is identified, handle this in the application, choose another library, or rely on another mitigation.
Summary
SSRF is very broad vulnerability class with a variety of potential exploitation scenarios and the potential for high impact. However, the impact is very context specific, depending on the behavior of the application and the environment the application server is in. Mitigation can be difficult, but the best solutions depend on a variety of controls to help prevent issues from known and unknown SSRF vulnerabilities.
