WebApp 101

WebApps 101: Server Side Request Forgery

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 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 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 and cause the webserver to issue the HTTP request against itself.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s