Ok. So you’ve found a feature on a web application that fetches external resources. You’re able to pull content from all sorts of external sites and there doesn’t seem to be any restrictions on the file type that you can request… The application displays everything right back at you. Everything on this endpoint is screaming at you, that it is ripe for SSRF! So you start typing in the magic digits: 127.0.0.1. But a mere second later, the server comes back with an unexpected response:
Error. Requests to this address are not allowed. Please try again.Well, frak. What do you do now?
(Pssst. If you aren’t familiar with SSRFs or need a refresher, here’s the first and second part of the series about SSRF.)
SSRF Protection Mechanisms
Companies have really caught onto the risk of SSRF attacks. As a result, most have implemented some form of SSRF protection on their web applications. There are two main types of SSRF protection mechanisms out there: blacklists and whitelists.
Blacklists refer to the practice of not allowing certain addresses and blocking the request if a blacklisted address was received as input. Most SSRF protection takes the form of blacklisting internal network address blocks.
On the other hand, whitelists mean that a server would only allow through requests that contain URLs on a prespecified list and fail all other requests.
Bypassing Whitelists
Whitelists are generally harder to bypass because they are by default, stricter than blacklists. But it is possible if there is an open redirect vulnerability within the whitelisted domains.
If you could find an open redirect, you can request a whitelisted URL that redirects to an internal URL.
If the whitelist is not correctly implemented (eg. via poorly designed regex), it could also be bypassed by using making a subdomain or directory as the whitelisted domain name (eg. victim.com.attacker.com or attacker.com/victim.com).
