Synopsys logo
Technical InsightWeb Application Security

How We Developed SSRF Detection to Help Protect Your Site

Developer Spotlight: Protecting Your Site from Server Side Request Forgery (SSRF)

The security landscape is always changing. As software developers, the challenges of learning the myriad of ways in which someone could attack our sites seems a daunting task. That’s why with the help of security scanning tools, we can check our code isn’t vulnerable without needing to know every vulnerability out there.

If you’ve used more traditional DAST scanners that crawl sites, you know they can be slow. Often this task is taken on by a dedicated security team and happens usually too late in the SDLC to remediate before going to production.

With Vantage Prevent, we can detect these vulnerabilities as part of the development process. The best part? It’s super fast.

Today we want to dive into how we tackle one of these vulnerabilities, Server Side Request Forgery (SSRF).

What is SSRF?

SSRF put simply, is when a server takes a resource as an input and requests that resource regardless of where it’s located.

Say for example you have a site that allows users to pick an avatar from a pre-set list of approved avatars. One of your users doesn’t quite like the set of avatars and decides to use their own. Using a tool such as Burp, they analyse the request when an avatar change is saved and notice there is a param called “URL”. Sure enough, that URL matches up with the image they chose on the site. They then get the clever idea of repeating the request, except this time, they replace the URL param with an image from another site.

This is a fairly benign example, but imagine your site requests a PHP resource, or some JS file. Without the right controls in place, this can lead to more sinister breaches. It can even form part of sophisticated attack chains that exploit further vulnerabilities such as remote code execution.

How Does Vantage Prevent Detect SSRF?

One of Vantage Prevents’ main goals is to be fast and to run anywhere. Whether it’s a developer building the site and running it locally, a QA running a scan against a staging environment from their laptop, or as part of a CI/CD pipeline. As such we chose probes that we believe will work in all of the above scenarios.

The two ways we do this are via SSRF Reflection and Blind SSRF. Both are surprisingly simple.

  • With reflection, we simply look at your site and if we detect that our payload is present (I.e., it’s “reflected” on the site) then we mark that URL as vulnerable.
  • With Blind SSRF detection we do out of band testing to try and determine if your web server requested a third-party resource even if we couldn’t find evidence of it reflected on the site. Even if we can’t see our payload on your site, you still want to know if your server even attempted the connection. Often these connection attempts result in 500 errors or worse, they silently carry out the request with no indication anything went wrong. Potentially running executable code on the server.

In order to achieve this, we manipulate any parameters we see that look like a URL or IP address as an input. We then substitute these values with our Hosted Attack Listener (affectionately called HAL).

HAL is a simple REST service written in Go that has one simple task. Listen for incoming requests and to respond to queries for that request. In order to ensure privacy, we don’t log anything about the request other than the ID passed to the listener. In addition, this ID is only stored for 10 minutes.

The listener passes back a static payload which we use for Reflected SSRF attacks and provides an endpoint for us to query for Blind SSRF attacks. If we logged your request, then your server tried connecting to ours.

Protecting Your Site with Vantage Prevent

Vantage Prevent provides a detailed report describing any vulnerabilities we found along with evidence and steps to remediate these sorts of attacks. By introducing security scanning earlier in the SDLC you can catch this vulnerability (and more!) when developing, QA testing, or even during your build process