What Is SSRF Attack?
Web applications often trigger requests between HTTP servers. These requests are typically used to fetch remote resources such as software updates, retrieve metadata from remote URLs, or communicate with other web applications. If not implemented correctly, these server-to-server requests can be vulnerable to server-side request forgery (SSRF).
SSRF is an attack that allows an attacker to send malicious requests to another system through a vulnerable web server. SSRF vulnerabilities listed in the OWASP Top 10 as a major application security risk can lead to sensitive information disclosure, enable unauthorized access to internal systems, and open the way to more dangerous attacks.
In this article:
- Risks of SSRF Attacks
- Types of SSRF Attacks
- Capital One: A Real-World SSRF Attack Example
- SSRF Protection with Bright Security DAST
Risks of SSRF Attacks
A successful SSRF attack allows a hacker to manipulate the target web server into executing malicious actions or exposing sensitive information. This technique can cause serious damage to an organization. Here are some of the main targets of SSRF attacks.
Sensitive Data Exposure
Sensitive data is the most popular target of SSRF attacks. Attackers typically submit malicious URLs to induce the server to return system information, allowing the attackers to escalate the attack. For example, an attacker might obtain credentials to access the server and create damage—the higher the privilege level of the exposed credentials, the higher the risk. If an attacker obtains admin credentials, it could control the whole server.
Cross-Site Port Attack (XSPA)
While not every SSRF attack returns confidential data to the attackers, some metadata allows attackers to learn about the server. For instance, information about the request’s response time helps determine if a request is successful. If attackers identify a valid host and port pair, they can scan the network for ports to execute a cross-site port attack.
Usually, the network connection’s timeout does not change regardless of the port or host. Attackers can send requests that are certain to fail to provide a response time baseline. Typically, a successful request will have a shorter response time than this baseline. This knowledge allows the attackers to fingerprint services that run over the network and execute protocol smuggling attacks.
Denial of Service (DoS)
Denial of service attacks flood the target server with large volumes of requests, causing it to crash. DoS attacks are common, with many real-world examples. An SSRF-based DoS attack targets the internal servers of a network.
Internal servers are typically vulnerable to DoS attacks because they don’t support large traffic volumes. Their low-bandwidth configuration makes sense because they normally receive far fewer requests than a public-facing server. Attackers can mount SSRF attacks to send large traffic volumes to the target system’s internal servers, taking up the available bandwidth and crashing the servers.
Remote Code Execution (RCE)
Many web services have a fully HTTP-based interfacing design. If a server lacks the safeguards to protect URL access, attackers could exploit a web service to access the server. Once the attackers gain access to the server, they might perform a remote code execution attack. The ability to execute malicious code can damage the system in various ways.
Related content: Read our guide to SSRF mitigation.
Types of SSRF Attacks
Server-side request forgery attacks usually exploit the trust between the server or another back end system and the compromised application, allowing attackers to escalate the attacks to perform malicious actions. Here are some examples:
SSRF Targeting the Server
SSRF attacks often target the server, with the attacker inducing the vulnerable application to send HTTP requests to the hosting server. Usually, the attacker provides a URL pointing to a loopback adapter.
For instance, an eCommerce application might allow users to see if a product is in stock by querying a REST API on the back end. It implements this function by passing a URL to the API via a front end request—the browser makes an HTTP request to provide the user with the relevant information.
However, attackers can exploit this functionality by modifying requests and specifying a local URL like the admin host, inducing the server to retrieve the admin URL’s contents. Normally, only authorized users can access the admin, but attackers can use this workaround to bypass access controls and obtain full administrative access. It works because the server thinks the request comes from a trusted location.
SSRF Targeting the Back End
Another way that SSRF exploits trust is when an application server can interact with back end systems that users cannot normally access. These systems typically have a private, non-routable IP address with a weak internal security posture. An unauthorized user can access protected functionality by interacting with a back end system.
For instance, attackers can exploit administrative interfaces at the back end by submitting a request for the admin URL’s content.
Blind SSRF attacks occur when the host server does not return visible data to the attackers. They work by focusing on performing malicious actions rather than accessing sensitive data. An attacker may tamper with user permissions or sensitive files on the server. For instance, the attacker might change the URL for the API call to induce the server to retrieve a large file repeatedly. Eventually, the server could crash, causing a denial of service (DoS).
Capital One: A Real-World SSRF Attack Example
Capital One Financial migrated its IT operations to the cloud, and deployed a web application firewall (WAF), but failed to notice it was misconfigured. Attackers discovered this, and used the WAF to send a request to an internal identity and access management (IAM) service. They relied on their knowledge of the IP address used for the IAM service by Capital One’s cloud provider. This service was inaccessible to traffic sources outside the cloud, but trusted and accepted requests from internal network elements, including the WAF.
The attackers received a response containing credentials for the WAF’s compute instance. They then used these credentials to query cloud storage resources, discover their contents, and systematically exfiltrate the data to an external web repository.
This attack relied on three gaps in Capital One’s security posture:
- WAF misconfiguration—the WAF did not properly filter the initial request. This allowed attackers to query the IAM service and receive a response.
- Excessive permissions—if the WAF’s IAM role had been appropriately restricted, the attacker could not have used its credentials to do much. A WAF usually does not need access to cloud storage systems.
- No SSRF detection—because there was no monitoring in place for SSRF attacks, Capital One only discovered the attack several months later.
SSRF Protection with Bright Security DAST
Bright Security’s dynamic application security testing (DAST) helps automate the detection and remediation of many vulnerabilities including SSRF, early in the development process, across web applications and APIs.
By shifting DAST scans left, and integrating them into the SDLC, developers and application security professionals can detect vulnerabilities early, and remediate them before they appear in production. Bright Security completes scans in minutes and achieves zero false positives, by automatically validating every vulnerability. This allows developers to adopt the solution and use it throughout the development lifecycle.
Scan any web app, or REST, SOAP and GraphQL APIs to prevent SSRF vulnerabilities—try Bright Security free.