Server Side Request Forgery (SSRF) is when you’re able to get a webserver to issue web requests on your behalf. In typical SSRF examples, the attacker might cause the server to make a connection back to itself, or to other web-based services within the organization’s infrastructure, or to external third-party systems.
Testing for SSRF
Keep an eye out for any time a URL is included inside a parameter. If you ever spot this, there is a very good chance that the webserver is calling on another webserver in order to display content on the page. You may be able to adjust which destination web server gets used and get malicious.
Example: You may have a vulnerable domain that looks like this.
By modifying the ?url parameter, we can force the webserver to submit a HTTP request to a target of our choosing.
Bypassing Blacklist Mitigation
If the webadmin decides to take a blacklist approach in an attempt to mitigate this vulnerability, we may be able to get creative to execute this vulnerability a different way.
Example: You may have a vulnerable domain that looks like this, but the page no longer works because 127.0.0.1 is on a blacklist.
To bypass this, we can try specify the same address using the hostname rather than the IP address.
You could also use one of the additional methods to say localhost.
Common Regex Misconfiguration
In an attempt to mitigate SSRF, a webadmin may use Regular Expressions in a whitelisting approach to only allow specific webpages to be supplied in the request. If they misconfigure their Regex, we may be able to abuse this to our advantage.
Example: You may have a vulnerable domain that looks like this, but it is not vulnerable to SSRF in the same way my previous examples have been. You find that you’re unable to remove website.com without the page returning an “Invalid URL” error.
However, you notice that the page still loads successfully when you append a period (.) to the URL within the parameter.
This indicates that the Regex was not configure properly. Let’s go out and register a malicious domain name, and configure a DNS zone so that any subdomain will route to 127.0.0.1. Since Regex isn’t configured properly, the following web request will bypass the filter and be executed by the sever.
Because of the DNS Zone, website.com.malicous.com will resolve to 127.0.0.1 and cause the webserver to issue the HTTP request against itself.