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.

http://example.com/?url=https://website.com/hacker.txt

By modifying the ?url parameter, we can force the webserver to submit a HTTP request to a target of our choosing.

http://example.com/?url=http://127.0.0.1:1234


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.

http://example.com/?url=https://127.0.0.1:1234

To bypass this, we can try specify the same address using the hostname rather than the IP address.

http://example.com/?url=http://localhost:1234

You could also use one of the additional methods to say localhost.

http://example.com/?url=http://127.0.0.2:1234
http://example.com/?url=http://017700000001:1234


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.

http://example.com/?url=http://website.com/hacker.txt

However, you notice that the page still loads successfully when you append a period (.) to the URL within the parameter.

http://example.com/?url=http://website.com./hacker.txt

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.

http://example.com/?url=http://website.com.malicous.com/hacker.txt

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.

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