Bypassing Perimeters via Request Misrouting and Cache-Based SSRF Escalation

TLDR: Modern web perimeters rely on reverse proxies and load balancers that often possess hidden, exploitable logic. By manipulating HTTP headers and absolute URLs, attackers can misroute requests to internal infrastructure or escalate simple XSS into full SSRF through pre-emptive caching. Pentesters must move beyond testing the application logic and start targeting the "invisible" infrastructure gatekeepers using out-of-band testing techniques.

Most of us treat load balancers and reverse proxies as transparent infrastructure. We test the application logic sitting behind them, assuming the proxy is a dumb pipe that simply passes traffic along. This is a massive mistake that leaves some of the most critical vulnerabilities on the table. These systems are complex, often misconfigured, and possess their own processing logic that can be subverted to bypass perimeters entirely. If you are not testing the proxy itself, you are not testing the full attack surface.

Subverting the Gatekeeper: Request Misrouting

Reverse proxies use the Host header to determine which backend server should receive a request. In many environments, this mechanism is surprisingly fragile. If a proxy is configured to trust the Host header without validation, an attacker can simply swap the legitimate hostname for an internal IP address or a private domain name. This is the essence of request misrouting.

During his research, James Kettle identified multiple high-profile targets where this simple swap allowed access to internal management interfaces. In one instance involving Yahoo, a load balancer was found to route traffic based on the Host header. By sending a non-standard HTTP command, Kettle was able to access an administrative "Overseer" port. This interface allowed for the modification of configuration settings across Yahoo's front-end infrastructure, eventually resulting in a 15,000 dollar bug bounty.

The technical execution is straightforward but requires precision. You can test for this by sending a request where the Host header points to a collaborator-controlled domain. If you receive a DNS or HTTP interaction, the proxy is misrouting your request.

GET / HTTP/1.1
Host: internal-admin-panel.local

If the proxy is even more permissive, it might support absolute URLs in the request line. Standard HTTP allows for GET http://example.com/ HTTP/1.1. If the proxy prioritizes the request line over the Host header, you can often bypass Host-based routing restrictions entirely.

Exploiting Auxiliary Systems and Analytics

Attackers often overlook the auxiliary systems that process HTTP traffic in the background. These include analytics engines, cache crawlers, and link pre-renderers. These systems frequently fetch URLs found in headers like Referer or X-Wap-Profile to perform background tasks.

The X-Wap-Profile header is a relic of the mobile web, intended to point to an XML file describing a device's capabilities. Many modern systems still attempt to fetch the URL specified in this header to parse the XML. This creates a classic Server-Side Request Forgery (SSRF) vector. Because these fetches often happen asynchronously, they are invisible to standard scanners. This is why Out-of-band Application Security Testing (OAST) is mandatory. Tools like Collaborator Everywhere automate the injection of these headers into every request, allowing you to catch delayed interactions from backend systems you didn't even know existed.

Escalating XSS to SSRF via Pre-emptive Caching

The most sophisticated technique revealed in this research involves escalating a limited Cross-Site Scripting (XSS) vulnerability into a full-blown SSRF by abusing proxy caching logic. Some high-performance reverse proxies scan the body of an application's response for resource imports, such as <img> or <script> tags, and pre-emptively fetch those resources to populate the cache.

If you find a reflected XSS vulnerability, you can inject a tag that points to an internal sensitive resource.

<img src="http://192.168.1.1/admin/config.php">

When the proxy sees this tag in the response, it attempts to be helpful by fetching the "image" from the internal IP. It then stores the result in its cache. As the attacker, you simply need to request that same URL from the proxy. The proxy will serve the cached content of the internal configuration page directly to you. This bypasses the need for the victim's browser to ever reach the internal network, as the proxy does the heavy lifting itself. This technique effectively turns a client-side bug into a critical server-side breach.

Real-World Impact and the OAST Necessity

The impact of these vulnerabilities is almost always critical. Accessing internal metadata services, management consoles, or unauthenticated backend APIs can lead to full environment takeover. We recently saw a resurgence of these patterns in new SSRF techniques affecting major browsers, proving that the interaction between infrastructure and application logic remains a primary weak point.

For a pentester, the methodology must change. You cannot rely on seeing a direct response in your proxy history. You must use an OAST listener and spray a variety of headers across the entire infrastructure. This includes testing not just the main application, but every IP in the target's range. Often, the most vulnerable proxies are the ones sitting in front of "boring" or legacy systems that have been forgotten by the security team.

Hardening the Perimeter

Defending against these attacks requires a shift in how we configure edge devices. Reverse proxies should never trust user-supplied headers for routing logic without strict allow-listing. If a proxy must fetch external resources, it should be isolated in a dedicated DMZ with no route to the internal network. Furthermore, backend systems like crawlers and analytics engines must be treated as untrusted users. They should be sandboxed and restricted from accessing internal IP ranges or sensitive metadata services.

Stop looking through the proxy and start looking at it. The next time you are on an engagement and the application logic seems solid, turn your attention to the headers. Use custom toolsets to inject OAST payloads into every possible field. The most devastating bugs are often hiding in the infrastructure logic that everyone else assumes is just working as intended. Go download the latest version of the research tools and point them at your next target. You might be surprised at what pings back.