Full Report
TL;DR This post is a summary of the contents of my talk in Defcon 31 AppSec Village last August 2023, and part of what I will explain in Canada at the SecTor conference on the 24th of October 2023 at 4:00 PM. There are two (big) blocks in this post. Sorry for the length : The first part is about the not so well-known CSP bypasses that I found during this research. These can be of use in your next pentest, bug bounty, etc. Have a look at the 8 third-party domains that can be abused to bypass a strict policy to execute that sweet Cross-Site Scripting (XSS) or clickjacking proof of concept that was initially being blocked. The second part takes a step back and delves into the process of getting Content-Securiy-Policy (CSP) data from top 1 million sites and the conclusions I draw from it. After reading this part you will get a sense of how widespread and well-implemented CSP is across the Internet. You will also learn the common pitfalls people fall into when implementing the policy. The tool I wrote to scan and collect this information and review the results can be found in https://github.com/sensepost/dresscode Index Context Bypasses Lab Environment Hotjar Facebook JSDelivr Amazon AWS Cloudfront, Azure, Heroku, Firebase CSP Health Status The Architecture Dashboard – CSP Health Status Conclusions Context Last year I was working on a web application assessment, one of these assessments that are repeated every year in which the analyst has to face a hardened application. Therefore, every year, the report gets smaller and smaller when we look at the number of vulnerabilities.
Analysis Summary
# Vulnerability: Content Security Policy (CSP) Bypass via Third-Party Domain Abuse
## CVE Details
- CVE ID: Not Specified (Research finding, not formally tracked as a CVE in this summary)
- CVSS Score: Not Specified
- CWE: CWE-269 (Improper Restriction of Impersonation) or related to CWE-79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')) as the resulting impact.
## Affected Systems
- Products: Web applications utilizing Content Security Policy (CSP) headers with overly permissive `script-src` directives. The research specifically targeted bypasses leveraging eight (8) specific third-party domains that were allowed within these policies.
- Versions: Indeterminate; dependent on the CSP configuration of the target application.
- Configurations: Any site where CSP allows script execution from third-party domains (e.g., specific domains like Hotjar, Facebook, JSDelivr, AWS CloudFront, Azure, Heroku, Firebase) without adequate restriction (e.g., lack of Subresource Integrity (SRI) or overly broad domain wildcards).
## Vulnerability Description
The research uncovered eight third-party public domains that can be abused to bypass existing Content Security Policy (CSP) implementations, enabling an attacker to execute Cross-Site Scripting (XSS) or perform Clickjacking attacks against sites that trust these domains in their CSP configuration.
The primary mechanism involves injecting malicious JavaScript through legitimate, allowed execution paths relying on these third-party services. Examples of services mentioned where bypass vectors were found include: **Hotjar**, **Facebook**, **JSDelivr**, **Amazon AWS**, **Cloudfront**, **Azure**, **Heroku**, and **Firebase**. The research implies that nearly 9% of sites defining a CSP were potentially vulnerable due to trusting one of these eight vectors.
## Exploitation
- Status: PoC available (The speaker developed and demonstrated these bypasses for research/pentesting use).
- Complexity: Likely Low to Medium, depending on the specific CSP enforcement (e.g., if `unsafe-inline` or `unsafe-eval` were implicitly allowed via the third-party mechanism).
- Attack Vector: Network (via injected stored or reflected XSS payloads that leverage the approved third-party domain to execute arbitrary code).
## Impact
- Confidentiality: High (Potential for credential harvesting or session hijacking via XSS).
- Integrity: High (Execution of arbitrary code in the context of the user's session).
- Availability: Low (Typically focused on client-side manipulation, not system availability).
## Remediation
### Patches
- No specific application patches are listed, as this is a configuration issue on the victim's side. The solution lies in hardening the CSP configuration on the deployed web application.
### Workarounds
1. **Reduce Third-Party Domains:** Minimize the number of allowed third-party domains in the CSP back to the absolute minimum required.
2. **Avoid Wildcards:** Do not use wildcards (e.g., `*.amazonaws.com`) in `script-src`. Specify exact hostnames.
3. **Use SRI:** Implement Subresource Integrity (SRI) checks for all third-party scripts to ensure the content has not been tampered with.
4. **Migrate Away from `unsafe-inline`/`unsafe-eval`:** Move towards strict policies using `nonce` or `hash` directives instead of these directives.
5. **Use `strict-dynamic`:** Consider this directive to ease adoption of strict policies, but be aware it allows permitted scripts to load other scripts.
## Detection
- **Monitoring:** Implement `report-to` and `report-sample` directives in the CSP header to receive real-time notifications of policy violations, which can indicate attempted or successful exploitation.
- **Tooling:** Monitoring client-side JavaScript execution for indicators of compromise related to known bypass payloads targeting these specific third-party domains.
- **Audit:** Regularly review CSP headers using tools (like the author's publicly available tool `dresscode`) to identify overly permissive or wildcard entries pointing to known high-risk or abused third-party services.
## References
- Talk Presentation Summary: SensePost | Dress Code – The Talk (Published August 2023)
- Tool for collection and review: hXXps://github.com/sensepost/dresscode
- Presentation at SecTor conference: October 24, 2023 (Details about the talk presentation structure).