Hellooo………

While performing security testing on a website, I identified a Blind Server-Side Request Forgery (SSRF) vulnerability triggered through an enabled HTTP TRACE (Cross-Site Tracing — XST) method.

This blog explains how the issue works, why it is dangerous, and how organizations can prevent it.

⚠️ Note: The vulnerability was responsibly disclosed. Sensitive details have been omitted.

Understanding the Concepts

What is SSRF?

Server-Side Request Forgery (SSRF) occurs when an application allows attackers to force the server to make HTTP requests to unintended destinations.

Instead of attacking directly from the outside, the attacker uses the vulnerable server as a proxy to:

  • Access internal services
  • Reach restricted IP ranges
  • Interact with cloud metadata endpoints

What is Blind SSRF?

Blind SSRF is more subtle.

  • The attacker does not see the response.
  • However, the server still makes the request.
  • Detection is done via out-of-band interactions (DNS/HTTP callbacks).

This makes it harder to detect and more dangerous in production environments.

What is XST (Cross-Site Tracing)?

XST is related to the HTTP TRACE method.

The TRACE method:

  • Echoes back the request sent to the server.
  • Can expose request headers.
  • Is rarely required in modern applications.

If TRACE is enabled, it may:

  • Leak authentication headers
  • Reflect cookies (if not properly secured)
  • Assist in chaining attacks like SSRF

Proof Of Concept:

Step1: I noticed the application allows TRACE method.

None

Step2: To confirm TRACE method allowed or not.I added header and gave XSS payload in the application it is reflected in headers response.

None

Step3: Successfully xss payload got executed.

None

Step4:Further testing showed that certain user-controlled inputs triggered outbound server-side requests.

None

Step5:No response data was visible — indicating a Blind SSRF scenario.Out-of-band monitoring confirmed server-side interaction.This meant the server could be forced to make requests to arbitrary endpoints.

None

Why This Is Critical

Blind SSRF can be used to:

  • Perform internal port scanning
  • Access internal admin panels
  • Interact with cloud metadata services
  • Bypass IP-based restrictions
  • Potentially escalate to RCE (in specific environments)

When combined with TRACE:

  • It increases the attack surface.
  • It exposes request manipulation vectors.
  • It helps in refining payload delivery.

In cloud environments, this can lead to credential theft if metadata endpoints are accessible.

Possible Attack Scenario

An attacker could:

  1. Send a crafted request containing a malicious URL.
  2. Force the vulnerable server to request internal resources such as:
  • 127.0.0.1
  • (cloud metadata)
  • Internal service ports

3. Use DNS-based callbacks to confirm exploitation.

4. Enumerate internal infrastructure.

Even without seeing the response, attackers can map internal networks.

Root Causes

  • HTTP TRACE method enabled unnecessarily
  • Lack of outbound request filtering
  • Improper input validation
  • Absence of SSRF protections
  • No network segmentation

Mitigation Recommendations

Organizations should:

✔ Disable the HTTP TRACE method ✔ Restrict outbound server traffic (egress filtering) ✔ Implement strict URL allowlists ✔ Block access to internal/private IP ranges ✔ Protect cloud metadata endpoints ✔ Use WAF rules for SSRF detection ✔ Implement network segmentation

Final Thoughts

Security is not just about finding vulnerabilities — it's about understanding how small misconfigurations can be chained into serious exploitation paths.

If you are conducting VAPT, always test:

  • Uncommon HTTP methods
  • Outbound request behavior
  • Internal network accessibility

Because sometimes, the server itself becomes the attacker.

Thank you…..