What Is SSRF?
A Server-Side Request Forgery (SSRF) attack involves an attacker abusing server functionality to access or modify resources. The attacker targets an application that supports data imports from URLs or allows them to read data from URLs. URLs can be manipulated, either by replacing them with new ones or by tampering with URL path traversal.
Typically, attackers supply a URL (or modify an existing one) and the code running on the server reads or submits data to it. Attackers can leverage URLs to gain access to internal data and services that were not meant to be exposed – including HTTP-enabled databases and server configuration data.
Once an attacker has tampered with the request, the server receives it and attempts to read data to the altered URL. Even for services that aren’t exposed directly on the public internet, attackers can select a target URL, which enables them to read the data.
SSRF Risks Explained
What damage SSRF might do depends entirely on the configuration of systems and the attacker’s inventiveness. Here are some common risks of SSRF.
Data Exposure
One of the most prevalent examples of an SSRF attack is gaining access to Amazon EC2 instance credentials. If an IAM role is attributed to an EC2 instance, the provisional credentials may be accessed by completing a request to:
http://169.254.169.254/latest/meta-data/iam/security-credentials/{role-name}
The level of damage that can be caused by the attacker depends on the level of access given to the IAM role. The higher the privileges of the role, the bigger the breach.
For application servers, this tends to indicate that, at the least, a cybercriminal will be capable of retrieving customer information. If excessive permissions are granted to the IAM role, attackers may be able to execute code remotely on EC2 instances within the target’s AWS account.
Reconnaissance
A common security practice used to minimize the attack surface from external networks is to limit the use of public-facing servers. The remaining servers are reserved for internal communication. SSRF allows attackers to carry out scans and collect information about internal networks. Once an attacker has gained access to the server, they can use this information to compromise other servers within the network.
Port Scans or Cross Site Port Attack (XSPA)
SSRF attacks don’t always return data to the attacker. Response times or other metadata, however, can allow an attacker to determine if a request was successful or not. If a port and a host can be pinpointed, the attacker could port scan the application server’s network by leveraging this metadata in a Cross-Site Port Attack (XSPA).
The timeout for a network connection generally remains unchanged, irrespective of the host or port. An attacker could thus attempt a request they know will file, and use this as a baseline for future response times. Requests that are successful will tend to be markedly shorter than this baseline, and occasionally longer if the connection established is not secured by one of the parties.
By working this way, attackers can fingerprint the services being carried out on the network, which allows them to initiate protocol smuggling attacks.
Denial of Service (DoS)
The volume of requests received by the internal servers is typically lower than the traffic to public-facing servers. Thus, they are configured to incur lower bandwidth. Cybercriminals may utilize SSRF to flood the internal servers with large amounts of traffic to take up their bandwidth, which results in an internal DoS attack.
Aside from these prevalent attacks, cybercriminals may employ SSRF to carry out malicious or unauthorized actions or to embed malware. The greater knowledge organizations have about these risks, the more alarming it becomes. However, there are measures you can take to stop these attacks.
Remote Code Execution (RCE)
Certain modern services are intended to be entirely interfaced via HTTP queries. Unlimited control of the URL may therefore allow the cybercriminal to exploit certain services, which could result in anything—even remote code execution on the core server (a well-known example is Redis).
Types Of SSRF Attacks
SSRF attacks commonly exploit a trust relationship, within the server itself (known as a server SSRF attack) or between the server and other back-end systems (known as a back-end SSRF attack).
Server SSRF Attacks
In a server SSRF attack, attackers exploit a process in which a browser or other client system directly accesses a URL on the server. The attacker will replace the original URL with another, typically using the IP 127.0.0.1 or the hostname “localhost”, which point to the local file system on the server. Under this hostname the attacker finds a file path that leads to sensitive data.
How Server SSRF works
For example, on a weather website, the web application queries its server for current weather forecasts to display. It can do this using a REST API, passing a URL with an API request from the user’s browser to the server. The request might look like this:
POST /meteorology/forecasts HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 113 weatherApi=http://data.weatherapp.com:8080/meterology/forecasts/check%3FcurrentDateTime%3D6%26cityId%3D1 The attacker can change this to the following: weatherApi=http://localhost/admin
This will cause the server to display the contents of the /admin folder to the attacker. Because the request is executed within the server’s file system, it bypasses ordinary access controls and exposes the information even though the attacker is unauthorized.
Back-End SSRF attacks
Another variant on SSRF is when a server has a trusted relationship with a back-end component. If, when the server connects to that component, it has full access rights, an attacker can forge a request and gain access to sensitive data, or perform unauthorized operations. Back-end components often have weak security because they are considered to be protected inside the network perimeter.
Continuing the previous example, the attacker could replace the API call with:
weatherApi=http://192.168.12.5/admin
If the server connects to a back-end component on IP address 192.168.12.5 and is allowed to access the /admin directory on that component’s file system, the attacker can similarly gain access and view the content of the directory.
Mitigating Server-Side Request Forgery
It is common to apply regular expressions and simple blacklists to user input, in order to mitigate SSRF and similar attacks. However, generally speaking, blacklists are an ineffective method of security control. Attackers can easily discover ways to get around them. For example, a cybercriminal may employ a wildcard DNS service, an HTTP redirect, or an alternate IP encoding.
Whitelists and DNS Resolution
A solid approach to avoiding SSRF is to whitelist the IP addresses or DNS names that your application requires access to. Only if a whitelist approach is not suitable should you use a blacklist. It is essential that you authorize user input effectively. For instance, do not permit requests to private IP addresses (which are non-routable).
In the instance of a blacklist, the appropriate mitigation strategy will differ according to the application. Thus, there is no one-size-fits-all fix to SSRF, as it is very dependent on organizational demands and application functionality.
Response Handling
To stop response information from reaching the cybercriminal, you should make sure that the response that is received conforms to what is anticipated. On no account should the raw response body received from the request initiated by the server be transferred to the client.
Disable Unused URL Schemas
If your application is solely reliant on HTTPS or HTTP to initiate requests, permit only these URL schemas. By disabling unused URL schemas, you deny attackers the ability to utilize the application to carry out requests via potentially harmful schemas, including dict://, file:///, and gopher://.
Authentication on Internal Services
Services like Redis, MongoDB, Elasticsearch, and Memcached do not demand verification by default. A cybercriminal may gain access to certain services without verification, using SSRF vulnerabilities. Thus, to enforce web application security, it is desirable to allow verification whenever you can, including for local network services.
Imperva SSRF Protection
Imperva provides a Web Application Firewall, which can prevent SSRF attacks, and many other application layer attacks, with world-class analysis of web traffic to your applications.
Beyond SSRF protection, Imperva provides comprehensive protection for applications, APIs, and microservices:
Runtime Application Self-Protection (RASP) – Real-time attack detection and prevention from your application runtime environment goes wherever your applications go. Stop external attacks and injections and reduce your vulnerability backlog.
API Security – Automated API protection ensures your API endpoints are protected as they are published, shielding your applications from exploitation.
Advanced Bot Protection – Prevent business logic attacks from all access points – websites, mobile apps and APIs. Gain seamless visibility and control over bot traffic to stop online fraud through account takeover or competitive price scraping.
DDoS Protection – Block attack traffic at the edge to ensure business continuity with guaranteed uptime and no performance impact. Secure your on premises or cloud-based assets – whether you’re hosted in AWS, Microsoft Azure, or Google Public Cloud.
Attack Analytics – Ensures complete visibility with machine learning and domain expertise across the application security stack to reveal patterns in the noise and detect application attacks, enabling you to isolate and prevent attack campaigns.
Client-Side Protection – Gain visibility and control over third-party JavaScript code to reduce the risk of supply chain fraud, prevent data breaches, and client-side attacks.
