1.1.4 CSP困境以及升级

CSP被提出作为跨站脚本攻击手段之后的几年内，不断遇到各种挑战和问题。2016年12月，Google团队发布了一篇关于CSP的调研报告，题为“CSP is Dead，Long live CSP”。利用强大的搜索引擎技术，该团队分析了超过160万台主机上的CSP部署方式。

该团队研究发现，在加载脚本时最常被纳入白名单的15个域中，有14个安全性不足。因此，75.81%采用脚本白名单策略的主机，实际上允许了攻击者绕过CSP的限制。总结来说，它们发现在尝试限制脚本执行的策略中，有94.68%是无效的，并且高达99.34%的主机实施的CSP对防御XSS没有实质性帮助。

1.CSP类型

在这篇报告中，Google团队正式提出两种先前已被提出的CSP类型。

（1）Nonce Script

Nonce Script代码如下：

对于动态生成的nonce字符串，仅当script标签包含相应且值相等的nonce属性时，该script块才能被执行。

这个字符串生成可以在后端实现，并且每次请求都会重新生成。这样，无论哪个域被认为是可信的，只要确保加载的资源都是经过验证且可信的，就可以保证安全。

后端实现代码如下：

（2）Strict Dynamic

Strict Dynamic代码如下：

Strict Dynamic意味着由可信的JS代码生成的JS代码也是可信的。

这个CSP规则主要是为了适应各种现代前端框架而设计的。通过实施这个规则，可以显著减少为了适配框架而导致CSP规则过于宽松的情况发生。

Google团队希望通过这两种方法来解决因前端技术发展而产生的CSP相关问题。

2.绕过思路

然而，双方博弈总是不断升级。Google团队提出的两种方法存在如下问题。

（1）Nonce Script绕过

2016年12月，在Google团队提出Nonce Script CSP可以作为新的CSP趋势之后，Sebastian Lekies在圣诞节期间指出了Nonce Script CSP的一个严重缺陷。Nonce Script CSP对于纯静态的DOM XSS（文档对象模型跨站脚本攻击）漏洞几乎无法防御。随着Web 2.0时代的到来，前后端交互的场景越来越多。为了应对这种情况，现代浏览器配备了缓存机制。当页面中没有修改或者不需要再次请求后台时，浏览器会从缓存中读取页面内容。location.hash就是一个典型的例子。如果JS代码中存在由操作location.hash产生的XSS，那么这样的攻击请求不会经过后台，因此进行Nonce处理后的随机值不会刷新。这种CSP绕过方式曾经在CTF（Capture The Flag）网络安全竞赛题目中出现过。

除了最常见的location.hash，作者还提出了一种新的攻击方式，即通过CSS选择器来读取页面内容。

当匹配到相应的属性时，页面便会发起对应的请求。此时，页面上的变化仅限于CSS层面。这是一种纯静态的XSS，可以使CSP失效。

（2）Strict Dynamic绕过

2017年7月的BlackHat大会上，Google团队提出了全新的攻击方式——Script Gadgets。

Strict Dynamic的提出是为了适应现代框架，但Script Gadgets利用了现代框架的特性。Script Gadgets针对流行JavaScript库的绕过能力如图1-2所示。

下面是Script Gadgets的示例代码：

Script Gadgets本质上是动态生成的JS代码，因此对于新型CSP，几乎可以实现破坏性的绕过，如表1-2、图1-3所示。