介绍
内容安全策略 (CSP) 是一个特殊的 HTTP 标头，用于缓解某些类型的攻击，例如跨站点脚本 (XSS)。一些工程师认为 CSP 是抵御 XSS 等漏洞的灵丹妙药，但如果设置不当，可能会引入错误配置，从而使攻击者完全绕过 CSP。
内容安全策略 (CSP)
CSP 标头相当简单，您只需了解以下几点。首先，CSP 标头值由用分号 “;”分隔的指令组成。您可以将这些指令视为应用于您网站的策略。以下列出了这些指令，请注意，这些并非全部，而是最常用的指令：
default-src 可以作为其他所有内容的集合。script-src 描述我们可以从哪里加载 JavaScript 文件 style-src 描述我们可以从哪里加载样式表 img-src 描述我们可以从哪里加载图像 connect-src 适用于 AJAX 和 Websockets font-src 描述我们可以从哪里加载字体 object-src 描述我们可以从哪里加载对象 (<embed>) media-src 描述我们可以从哪里加载音频和视频文件 frame-ancestors 描述哪些网站可以在 iframe 中加载此网站
这些指令被设置为特定的值，用于定义哪些资源可以被加载以及从哪里加载。资源列表如下：
*从任何地方加载资源'none'阻止所有内容'self'只能从同一来源加载资源data:只能从数据模式（Base64）加载资源something.example.com只能从指定域加载资源https:只能通过HTTPS加载资源'unsafe-inline允许内联元素（onclick，<script></script>标签，javascript:，）'unsafe-eval'允许动态代码评估（eval（）函数）'sha256-'仅当与哈希匹配时才能加载资源'nonce-'如果脚本标签包含与CSP标头中指定的nonce匹配的nonce属性，则允许执行内联脚本或CSS。
现在您已经了解了 CSP 标头的结构，让我们来看一个例子。如下所示，您可以看到 CSP 在 HTTP 响应标头中返回。
default-src 'none'; base-uri 'self'; block-all-mixed-content; connect-src 'self' uploads.github.com www.githubstatus.com collector.githubapp.com api.github.com www.google-analytics.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-production-user-asset-6210df.s3.amazonaws.com wss://live.github.com;font-src github.githubassets.com;form-action 'self' github.com gist.github.com;frame-ancestors 'none';frame-src render.githubusercontent.com;img-src 'self' data: github.githubassets.com identicons.github.com collector.githubapp.com github-cloud.s3.amazonaws.com *.githubusercontent.com customer-stories-feed.github.com spotlights-feed.github.com; manifest-src 'self';media-src 'none'; script-src github.githubassets.com; style-src 'unsafe-inline' github.githubassets.com我们看到的第一件事是：default-src 'none';。基本上，这表示除非另有说明，否则阻止所有内容。我还看到：frame-ancestors 'none';。此策略将阻止其他站点在 iframe 中加载此站点，从而消除点击劫持漏洞。我们还看到：script-src github.githubassets.com;。此策略使站点只能从 github.githubassets.com 加载 javascript 文件，除非我们能在站点中找到绕过方法，否则基本上可以杀死 XSS。还定义了其他策略，看看它们在做什么。
基本 CSP 绕过
有很多方法会搞乱你的 CSP 实现。最容易导致 CSP 配置错误的方法之一就是在设置策略时使用危险的值。例如，假设你有以下 CSP 标头：
default-src 'self' *众所周知，default-src策略是一种“包罗万象”的策略。您也知道*是通配符。所以，这个策略基本上就是允许加载任何资源。这和没有 CSP 头是一样的！您应该时刻注意通配符权限。
让我们看看另一个 CSP 标头：
script-src 'unsafe-inline''unsafe-eval''self'data:https://www.google.com http://www.google-analytics.com/gtm/js https://*.gstatic.com/feedback/ https://accounts.google.com;这里我们有一个策略script-src，我们知道它用于定义可以从哪里加载 JavaScript 文件。通常情况下，像<IMG SRC=”javascript:alert('XSS');”>这样的代码会被阻止，但由于值为'unsafe-inline'，它会被执行。这一点需要时刻注意，因为它对攻击者来说非常方便。
您还可以看到值数据：如果您有数据：元素，这将允许您加载javascript，如下所示：
<iframe/src="data:text/html,<svg onload=alert(1)>">到目前为止，所有用于绕过 CSP 的技术都是由于配置错误或滥用 CSP 的合法功能造成的。此外，还有一些其他技术可以用来绕过 CSP。
JSONP CSP绕过
如果您不知道 JSONP 是什么，您可能需要查看一些相关的教程，但我会为您提供一个简短的概述。JSONP 是一种绕过相同对象策略 (SOP) 的方法。JSONP 端点允许您插入 JavaScript 有效负载，通常放在名为“callback”的 GET 参数中，然后端点会将有效负载以 JSON 的内容类型返回给您，从而绕过 SOP。基本上，我们可以使用 JSONP 端点来提供 JavaScript 有效负载。您可以在下面找到一个示例：
https://accounts.google.com/o/oauth2/revoke?callback=alert(1337)
Google JSONP 端点
正如您在上面看到的，我们的警报功能已显示在页面上。
当 CSP 标头中的某个端点在 script-src 策略中被列入白名单时，危险就来了。这意味着我们可以绕过 CSP 策略，通过 JSONP 端点加载恶意 JavaScript。
看一下以下 CSP 标头：
script-src https://www.google.com http://www.google-analytics.com/gtm/js https://*.gstatic.com/feedback/ https://accounts.google.com;这会被 CSP 阻止
something.example.com?vuln_param=javascript:alert(1);由于accounts.google.com被允许加载 JavaScript 文件，因此此漏洞可以正常利用。然而，我们却滥用 JSONP 特性来加载恶意 JavaScript。
something.example.com?vuln_param=https://accounts.google.com/o/oauth2/revoke?callback=alert(1337)CSP注入旁路
第三种 CSP 绕过类型称为 CSP 注入。当用户提供的输入反映在 CSP 标头中时，就会发生这种情况。假设您有以下 URL：
example.com?vuln=something_vuln_csp如果您的输入反映在 CSP 标头中，您应该会看到类似这样的内容。
script-src something_vuln_csp;object-src 'none';base-uri 'none';require-trusted-types-for'script';report-uri https://csp.example.com;这意味着我们可以控制script-src 的值。通过将此值设置为我们控制的域名，我们可以轻松绕过 CSP。
结论
CSP 是一个用于控制应用程序从何处加载其资源的标头。它通常用于缓解 XSS 和点击劫持等漏洞，但如果设置不当，则很容易被绕过。查找 CSP 注入或易受攻击的 JSONP 端点等内容是绕过 CSP 标头的简单方法。如果 CSP 设置不当，您可以利用 CSP 自身功能来绕过 CSP。例如，将“inline-scripts”和通配符应用于 script-src 策略时，始终存在危险。
参考
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
https://blog.detectify.com/2019/07/11/content-security-policy-csp-explained-cluding-common-bypasses/
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2019/april/a-novel-csp-bypass-using-data-uri/
https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/
原文始发于微信公众号（Ots安全）：内容安全策略（CSP）绕过
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论