1.1.3 CSP的绕过

CSP规则可以设定得极为严格，以致于有时会与众多网站的核心功能冲突。为了确保广泛的兼容性，CSP提供了多种灵活的模式以适应各类场景。然而，这种便利在为开发者提供灵活性的同时，也可能带来一系列安全隐患。

CSP在防御前端攻击方面主要采取两大措施：一是限制JavaScript代码的执行，二是限制对不可信域的请求。下面将探索若干种绕过CSP规则的策略。

1.第一种CSP规则代码

第一种CSP规则代码如下所示。

这是一个几乎没有任何防御能力的CSP规则，它允许加载来自任何域的JS代码。

2.第二种CSP规则代码

第二种CSP规则代码如下所示。

这是最普通、最常见的CSP规则，只允许加载当前域的JS代码。

网站通常会提供用户上传图片的功能，如果我们上传一个内容为JS代码的图片，图片就在网站的当前域下。

直接加载图片即可。

3.第三种CSP规则代码

第三种CSP规则代码如下所示。

当发现设置self并不安全的时候，你可能会选择把静态文件的可信域限制到目录。这种方法看似解决了问题，但是，如果可信域内存在一个可控的重定向文件，那么CSP的目录限制就可以被绕过。

假设static目录下存在一个302文件。

如之前所述，攻击者可以上传一个名为test的图片文件，然后利用302脚本实现重定向，将用户引导至upload目录下加载的JS代码，从而成功执行恶意代码。

4.第四种CSP规则代码

第四种CSP规则代码如下所示。

CSP不仅能阻止不可信的JS代码的执行，还能防止对不可信域的资源请求。

在上述CSP规则的约束下，如果我们尝试加载来自外部域的图片，该请求将被阻止。

在CSP的演变过程中，难免就会出现一些疏漏。

在CSP 1.0版本中，对于链接的限制并不完善，而且不同浏览器（包括Chrome和Firefox）对CSP规则的支持也有所差异。每个浏览器都维护着自己的一份CSP规则列表，这份列表通常包含CSP 1.0的规范、部分CSP 2.0的特性，以及少量的CSP 3.0功能。

5.第五种CSP规则代码

无论CSP有多严格，我们都无法预测开发者会写出何种代码。以下是Google团队发布的一份关于CSP的报告中的示例代码：

这段代码实现了将传入的字符串作为JS代码动态执行。实际上，许多现代前端框架都采用了类似机制。它们能够从特定的标签中提取字符串，并将其解析为JS代码。例如，AngularJS框架引入了ng-csp标签，以实现与CSP的完全兼容。

然而，即便在启用了CSP的环境中，一些现代框架仍能够正常运作。这表明在这些情况下，CSP可能并未发挥预期的安全防护作用。这突显了在实施CSP时，需要对框架的兼容性和安全性进行细致的考量和调整，以确保CSP规则能够有效地增强网站的安全性。

6.第六种CSP规则代码

第六种CSP规则代码如下所示。

可能你的网站并没有遇到这类问题，但你可能会采用JSONP技术来实现跨域数据获取，这种方式在现代Web开发中相当流行。然而，JSONP本质上与CSP存在冲突。因为JSONP旨在解决跨域请求的问题，它必须能够在可信域中执行，这与CSP限制不可信域代码执行的原则相悖。

通过这种方法，攻击者可以构造并执行任意的JS代码。即使CSP限制callback函数只能接收包含字母、数字字符（\w+）的数据，但某些情况下，部分JS代码仍有可能被执行。结合特定的攻击和场景，这可能导致安全威胁。

为了防范这种风险，最稳妥的做法是将返回数据类型设置为JSON格式。这样，即使攻击者尝试注入恶意代码，也只会将其作为数据处理，而不是作为可执行的代码，从而降低潜在的安全风险。

7.第七种CSP规则代码

第七种CSP规则代码如下所示。

与前面提到的CSP规则相比，以下所述的才是更为常见的CSP规则。

unsafe-inline是处理内联脚本的策略。当CSP规则中的script-src属性允许内联脚本时，页面中直接添加的脚本便能够被执行。

既然有能力执行任意的JS代码，接下来的问题便集中在如何巧妙地绕过对可信域的限制上。

（1）通过JS代码生成link prefetch

第一种办法是通过JS代码生成link prefetch：

这种办法只在Chrome浏览器中可用，但非常有效。

（2）跳转

在浏览器的机制中，跳转本身就是跨域行为：

通过发起跨域请求，我们能够将所需的各类信息传递出去。

（3）跨域请求

在浏览器中，存在多种类型的请求本质上是跨域的，包括表单的提交。而它们的共同特征就是包含href属性。