Full Report
Introduction What seemed like a regular Cross-site Scripting (XSS) vulnerability on an HTTP 500 “Internal Server Error”-page, I managed to turn into a one-click account takeover on an assessment. In this blog post I want to describe the path I took to achieve this leveraging a known Cloudflare WAF bypass and Google analytics to extract session tokens serving as a CSP bypass. Reconnaissance At the beginning of the assessment, it quickly came to my attention that the web application stored the Session ID as part of some kind of error reporting JavaScript function in a message variable. This function would be executed if window.error was triggered:
Analysis Summary
# Vulnerability: Chained XSS Leading to Account Takeover via WAF Bypass and Google Analytics Exfiltration
## CVE Details
- CVE ID: N/A (No specific CVE referenced for the application vulnerability; describes a technique leveraging known bypasses)
- CVSS Score: N/A (Score not provided in the source material)
- CWE: CWE-79 (Improper Neutralization of Input During Web Page Generation (Cross-site Scripting))
## Affected Systems
- Products: Web application processing the `EndUserVisibleHtmlMessage` parameter on an HTTP 500 error page.
- Versions: Not specified.
- Configurations: Application must be protected by Cloudflare WAF, utilize a specific error reporting function that exposes the Session ID in a JavaScript variable upon `window.error`, and have a Content Security Policy (CSP) that allows loading scripts from `https://ssl.google-analytics.com`.
## Vulnerability Description
The core issue is reflected Cross-Site Scripting (XSS) in the `EndUserVisibleHtmlMessage` parameter reflected on an HTTP 500 "Internal Server Error" page. This XSS vulnerability was chained with two additional factors:
1. **Cloudflare WAF Bypass:** A known bypass technique involving adding 8 or more superfluous leading zeros in decimal or 7 or more in hex, used to smuggle an `onload` event containing an `eval` function past the WAF.
2. **CSP Bypass via Data Exfiltration:** The application's CSP allowed script execution from `https://ssl.google-analytics.com`. The attacker leveraged this by injecting JavaScript that extracted the locally stored Session ID (exposed via an error reporting function) and encoded it into the tracking parameters of a GET request sent directly to the attacker's controlled Google Analytics endpoint (`/collect`). This effectively bypassed the CSP restriction on external data exfiltration.
## Exploitation
- Status: Proof-of-concept / Demonstration (Successfully executed in a proof-of-concept to achieve account takeover).
- Complexity: Medium (Requires knowledge of a specific, known Cloudflare WAF bypass and understanding of CSP/Google Analytics tracking mechanisms).
- Attack Vector: Network (Victim must click a crafted malicious link).
## Impact
- Confidentiality: High (Session tokens/IDs stolen).
- Integrity: High (Session hijacking leading to full account takeover).
- Availability: Low (Minimal impact on service availability).
## Remediation
### Patches
- No specific vendor patch referenced, as this targets a custom application flaw.
- **Application Fix:** Validate and sanitize all input used in the `EndUserVisibleHtmlMessage` parameter to prevent XSS injection.
- **WAF Configuration:** Ensure Cloudflare WAF settings are up-to-date to block known bypass signatures (like excessive zero padding).
### Workarounds
- **CSP Hardening:** Strictly limit `script-src` directives to essential domains and remove `'unsafe-inline'` and `'unsafe-eval'` if possible.
- **Session Management:** Avoid exposing sensitive identifiers like Session IDs in client-side error reporting mechanisms or JavaScript variables accessible via the DOM.
- **Ad Blockers/Tracking Prevention:** Note that users utilizing ad blockers or tracking prevention were immune to the data exfiltration step of this attack chain.
## Detection
- **Indicators of Compromise:** Unexpected outbound HTTP GET requests to Google Analytics `/collect` endpoints originating from client-side code, carrying potentially malformed or session-like data appended to tracking parameters (e.g., `&ea=`, `&ec=`).
- **Detection Methods and Tools:** Monitor web server logs for suspicious URIs that include WAF bypass signatures, especially on paths that return 500 errors. Monitor network traffic for unusual outbound connections to third-party analytics endpoints originating from the application's front-end.
## References
- SensePost Blog: hxxps://sensepost.com/blog/
- Google Analytics Protocol Details: hxxps://developers.google.com/analytics/devguides/collection/protocol/v1/parameters
- Previous GA Data Extraction Research: hxxps://labs.detectify.com/2018/01/19/google-analytics-data-extraction/