0dSSRF | Automate Finding SSRF & External Service Interactions & Open Redirects

Server-Side Request Forgery (SSRF) is a vulnerability where an attacker tricks the server into making unintended requests to internal or external services. SSRF can bypass network boundaries, reach restricted systems, or exfiltrate sensitive information.

SSRF isn’t limited to HTTP requests. Often, the vulnerability includes interactions with external services, such as DNS lookups or port scanning. Sometimes, the server’s interaction may only resolve to a DNS query without completing a full HTTP connection.

Although DNS lookups alone may not seem harmful, they could still indicate a potential vulnerability or system misconfiguration. Reporting these to the responsible team is worthwhile, as these subtle clues can lead to deeper issues or even rewards.

Update: now HackerOne triagers are considering this issue as informative.

To identify SSRF vulnerabilities effectively, I structured the discovery process into four stages. Each stage targets a different attack vector, ensuring a comprehensive assessment of the target application.

The first step focuses on manipulating the Host header. Some applications rely on the Host header for routing or validation, which makes it an attractive target.

Example:

By injecting a malicious value into the Host header, I can trick the server into making requests to the Burp Collaborator.

In this stage, I target commonly used HTTP headers, such as X-Forwarded-For, Referer, Origin, and others, which are frequently processed by servers during request routing.

Example:

the most common headers are

This stage often reveals SSRF vulnerabilities in web applications that trust user-controlled HTTP headers.

In the third stage, I focus on injecting absolute URLs directly into the requests. Certain web servers extract the hostname from the absolute URL and handle requests based on it. This behavior can be exploited if the server fails to properly validate the URL.

Example:

If the host header is different from the hostname in the absolute URL, the request may be redirected or handled differently by the server. If these URLs are not properly validated, it can lead to SSRF vulnerabilities.

This vector is particularly useful for cases where applications redirect requests based on the full URL or validate access based on it.

The final stage targets URL parameters where SSRF vulnerabilities often hide. By injecting the Burp Collaborator payload into various parameters, I can discover vulnerabilities that lie deep within the application logic.

Example

the most common parameters are

But!! By iterating through all possible parameters, this stage ensures that no potential entry point is missed.

Using the above methodology, I was able to discover five SSRF vulnerabilities in the same target. Each vulnerability was identified by carefully analyzing the server’s responses and correlating them with the Burp Collaborator logs.

To streamline the SSRF discovery process, I developed a custom Bash script, 0dSSRF. The script automates the injection of the Burp Collaborator payload across multiple vectors (headers, parameters, absolute URLS) and logs the results.

NOTE: The third stage, you can also use burp intruder, it would be better to catch reflective values or unpredictable behaviors.

Multiple Injection Methods: Automatically inject Burp Collaborator payloads into:

Flexible Scan Controls: Adjust the delay between requests for rate-limited environments.

Resumable Scanning: Continue from the last session if the scan is interrupted.

Structured Output & Logs: Save all results in a clean, organized directory structure for easy reference.

You can check the full script and more detailed instructions on GitHub:
GitHub: 0dSSRF

I’m eager to hear your feedback and suggestions on how it can be improved.

Monitoring Collaborator: Once you start the scan, check Burp Collaborator for DNS lookups or HTTP requests from the tested domains.

Interpreting Results: Vulnerable subdomains or vectors will appear in the collaborator’s log. For example:

Identifying Vulnerable Subdomains:

Vector Vulnerability Identification:

For the fourth stage, also requests carry information about the vulnerable server & parameter & time:

The SSRF vulnerability is a serious threat, and the right approach can help you uncover hidden risks. By automating the process with 0dSSRF, you can efficiently test for SSRF and external service interactions.

I hope you found this write-up helpful! Feel free to ask any questions, provide feedback, or suggest improvements for the tool. Happy hacking!

GitHub: 0dSSRF