DEV Community

Cover image for Server-side Request Forgery (SSRF)
GifHow
GifHow

Posted on

Server-side Request Forgery (SSRF)

#webdev #typescript #ssr

What is SSRF?

Server-side request forgery (SSRF) is a vulnerability that allows a perpetrator to manipulate the server application into sending requests to a desired address.

Note: This type of attack can come from various sources, but for the sake of simplicity, I will only cover SSRF that exploits untrusted user input.

Rather than connecting to random or malicious web addresses, the perpetrator often targets internal-only services. This could result in a major data breach if the server's infrastructure lacks proper security measures against such attacks. Not only that, with the already elevated access, the attacker can do much more damage to the server, including, but not limited to:

  • Internal Network Reconnaissance: Network discovery, port scanning with SSRF.
  • Remote Command Execution (RCE): If the SSRF interacts with services that allow command execution (e.g., Redis, Jenkins), RCE is possible.
  • Denial-of-Service (DoS): Attackers can overload internal systems by forcing the server to make repeated requests.

Common SSRF Attacks

The attacker first begins with finding an entry point. This could be:

  • A form input
  • An HTTP parameter
  • Via XXE
  • And more...

Example Scenario

My server has a PDF Generation service that accepts URLs provided by the user. It fetches the resources from the URL and returns the generated PDF file.

Without proper precautions, a bad actor could exploit this in several ways.

1. Private Network

What will happen if a user provides http://localhost/admin to the service?

The server fetches the contents of the /admin URL and returns it to the user.

Normally, the /admin page is only accessible to authenticated users. But if the request comes from the local machine (the server itself), access controls might be bypassed.

You might think blacklisting "localhost" solves it, but attackers can:

  • Use IP addresses like 127.0.0.1 or 0.0.0.0.
  • Use domains that resolve to localhost, e.g., fbi.com with a DNS A record pointing to 127.0.0.1.
  • Exploit DNS rebinding.

2. HTML External Resources

Attackers can inject malicious URLs within HTML content:

<!-- Image tag -->
<img src="http://localhost/admin">

<!-- CSS -->
<link href="http://attacker.com/malicious.css" rel="stylesheet">

<!-- JavaScript -->
<script src="https://attacker.com/malicious.js"></script>

<!-- SVG with XXE -->
<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100">
  <!DOCTYPE svg [
    <!ENTITY xxe SYSTEM "http://127.0.0.1/admin/">
  ]>
  <text>&xxe;</text>
</svg>
Enter fullscreen mode Exit fullscreen mode

Common SSRF Defenses

It is common to see applications containing SSRF behavior together with defenses aimed at preventing malicious exploitation. Often, these defenses can be circumvented.

1. Blacklist filter

As mentioned earlier, it's quite easy to bypass domain & IP blacklists.

Some applications block input containing hostnames like 127.0.0.1 and localhost, or sensitive URLs like /admin.

In this situation, the attacker can often circumvent the filter using the following techniques:

  • Alternative IP representations of 127.0.0.1 such as:
    • 2130706433
    • 017700000001
    • 127.1
  • Register a domain that resolves to 127.0.0.1 (e.g., spoofed.burpcollaborator.net, fbi.com could also resolve to 127.0.0.1)
  • Obfuscate blocked strings using:
    • URL encoding
    • Case variation
  • Use a redirect:
    • Provide a URL you control that redirects to the target
    • Try different redirect codes (e.g., 301, 302)
    • Switch protocol during redirect (e.g., from http: to https:) to bypass certain anti-SSRF filters

Common SSRF defenses

It is common to see applications containing SSRF behavior together with defenses aimed at preventing malicious exploitation. Often, these defenses can be circumvented.

Blacklist filter

As mentioned earlier, it's quite easy to bypass our domain & IP blacklist. Some applications block input containing hostnames like 127.0.0.1 and localhost, or sensitive URLs like /admin. In this situation, the attacker can often circumvent the filter using the following techniques:

  • Use an alternative IP representation of 127.0.0.1, such as 2130706433, 017700000001, or 127.1.
  • Register your own domain name that resolves to 127.0.0.1 (Domains like spoofed.burpcollaborator.net or fbi.com can also resolve to 127.0.0.1)
  • Obfuscate blocked strings using URL encoding or case variation.
  • Provide a URL that you control, which redirects to the target URL. Try using different redirect codes, as well as different protocols for the target URL. For example, switching from an http: to https: URL during the redirect has been shown to bypass some anti-SSRF filter.

Whitelist filter

Some applications only allow inputs that match a whitelist of permitted values. Though this method is more secure than blacklisting, there are still ways to bypass it if the filter looks for a match at the beginning of the input, or contained within it. You may be able to bypass this filter by exploiting inconsistencies in URL parsing.

The URL specification contains a number of features that are likely to be overlooked when URLs implement parsing and validation using this method:

  • Embed credentials in a URL before the hostname, using the @ character. For example: https://example.com:fakepassword@attacker.com
  • Indicate a URL fragment with the # character. For example: https://attacker.com#example.com
  • Leverage the DNS naming hierarchy to place required input into a fully-qualified DNS name that the attacker controls. For example: https://example.com.attacker.com
  • URL-encode characters to confuse the URL-parsing code. This is particularly effective if the code that implements the filter handles URL-encoded characters differently than the code that performs the back-end HTTP request.

Open Redirection

It is sometimes possible to bypass filter-based defenses by exploiting an open redirection vulnerability. Provided that the service/application used to make the back-end HTTP request supports redirections, an attacker may construct a URL that satisfies the filter and results in a redirected request to the desired back-end target.

For example, the application contains an open redirection vulnerability in which the following URL:

/item?itemId=22&callback=http://attacker.com

returns a redirection to:

http://attacker.com

This SSRF exploit works because the application first validates that the supplied URL is on an allowed domain, which it is. The application then requests the supplied URL, which triggers the redirection. It follows the redirection, and makes a request to the internal URL of the attacker's choosing.

Conclusion

SSRF is a dangerous vulnerability that can lead to significant security breaches if not properly mitigated. Attackers can exploit SSRF to access internal services, execute remote commands, or even cause denial-of-service attacks. Defenses such as blacklisting, whitelisting, and open redirection checks can be effective but are often bypassed by determined attackers. Simply put, you're screwed. Just kidding.

You can follow OWASP's official guide on how to prevent SSRF. But here's the gist: validate input with block-list & allowed-list, sanitize content (depending on application context), and resolve DNS before consuming the URL.

That's all for today. Stay safe, and never trust user input!

Follow us on

My Website : https://gif.how/

Facebook: https://www.facebook.com/Gif.how1

YouTube: https://www.youtube.com/@Gif.how1

X (Twitter): https://x.com/GifHow1

Pinterest: https://www.pinterest.com/gifhow1/

LinkedIn: https://www.linkedin.com/in/gif-how/

Bento: https://bento.me/gifhow

Top comments (0)