What is SSRF?
Server-side request forgery (SSRF) attacks allow an attacker to trick server-side applications into allowing access to the server or modifying files. SSRF can be successful if the target application reads data from a URL without sanitizing it.
If an SSRF vulnerability is present, attackers can manipulate URLs to send HTTP requests to a domain. They can do this by manipulating URL paths, or replacing URLs entirely. SSRF attacks often take advantage of URLs that point to internal services within an organization’s infrastructure. These URLs should not be accessible to outsiders, but attackers can use SSRF to gain access to them.
If successful, SSRF attacks can lead to unauthorized access to sensitive organizational data, such as login credentials. This can affect the web application itself, the backend system the web application depends on, or the external server the application communicates with.
In this article:
Consequences of an SSRF Attack
SSRF attacks can grant attackers access to privileged resources. Hackers often use SSRF attacks to access:
- Private IP addresses
- Internal resources behind firewalls
- Server loopback interfaces, “localhost”, typically accessed through http://127.0.0.1
- Cloud service metadata
- Internal APIs
- Privileged files on vulnerable servers
- Local ports (discovered via port scanning)
In addition, SSRF can help attackers hide the true origin of their connections. If an attacker already has access to a protected resource, or wants to attempt an attack against internal resources, they can use SSRF to avoid detection. The connection appears to have come from the backend of the local application and not from an external source.
In many cases, SSRF attacks are the first step of a multi-stage attack. The next stages after the SSRF exploit could be:
- Using SQL injection—after exploiting an SSRF vulnerability in an application, the attacker can access the database behind it and launch a SQL injection attack.
- Remote code execution (RCE)—after attackers exploit SSRF in an application, they can gain local access to the server running the application, gain full shell access, and then exploit operating system vulnerabilities on the underlying server.
- Other web application vulnerabilities—attackers can combine SSRF with other application layer vulnerabilities like XXE, XSS, or CSRF.
Learn more in our detailed guide to SSRF attack
7 SSRF Mitigation Techniques
Mitigating SSRF with Firewalls
A common way to mitigate SSRF is to enforce a firewall policy that specifies what hosts applications are allowed to connect to. The firewall could be located within the network infrastructure, near to hosts running application servers, or deployed directly on the host.
There are a few drawbacks to protection based on firewalls or access control lists (ACLs):
- Host-based firewalls cannot distinguish between connections established by applications as part of their normal operation or by other software on the same node.
- Firewalls can block outbound connections but would still allow certain connections, such as to other nodes within the same network segment.
A way to overcome these limitations is to use an HTTP CONNECT proxy. This type of proxy can forward all traffic and enforce ACLs to control where traffic is allowed to go. This can only work if the application supports HTTP CONNECT and can route traffic over it, but this is usually the case.
Mitigating SSRF with Application Controls
SSRF can be mitigated through application layer controls—the application can check a target address is allowed before creating a connection.
Note that it is not enough just to verify the address and establish a connection. This approach is still vulnerable to “time-of-check” and “time-of-use” vulnerabilities. These vulnerabilities involve an attacker who controls a DNS server and uses a short TTL to change the target address in the next DNS query. To mitigate this, use lower-layer hooks that can apply classless inter-domain routing (CIDR) checks and restrict HTTP redirects.
Whitelists and DNS Resolution
Possibly the most effective way to prevent server-side request forgery (SSRF) is to create an allowlist of hostnames (DNS names) or IP addresses the application needs to access.
If you cannot use an allowlist, create a denylist and ensure you perform proper validation of user input against this list. For example, do not allow requests to endpoints with private (non-routable) IP addresses. The range of addresses to deny can vary significantly—SSRF protection is highly dependent on the characteristics of your application and its environment.
Authentication on Internal Services
Many caching services and NoSQL databases do not require authentication by default. An attacker could use SSRF to access these services without authentication. Therefore, to protect sensitive information and secure web applications, it is critical to enable authentication for all services within your local network. This is also in line with the zero trust security approach.
Harden Cloud Services
Amazon Web Services (AWS), Azure, and other cloud vendors, enable SSRF mitigation by hardening their configuration. For example, AWS prevents access to cloud service metadata from containers.
However, these built-in protections are not enough. For example, a headless web engine like Chromium can allow attackers to circumvent some of these protections. It is important to set strong identity and access management (IAM) policies that restrict permissions your APIs have when communicating with cloud services.
Response Handling
To prevent disclosure of response data to an attacker, applications must validate all responses, and under no circumstances display the raw response body of a request sent to the client.
Disable Unused URL Schemas
Most application only make requests using HTTP or HTTPS, so only these URL patterns should be allowed. You can disable old or atypical URL schemes such as file:///, dict://, ftp://, and gopher:// to prevent attacks that exploit these protocols.
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 now.
