修复方案CSP绕过

修复方案CSP绕过：我那晚跟浏览器斗智斗勇的惊魂记

哎哟喂,说到CSP绕过这事儿，我现在后背还发凉呢！你们知道那种感觉吗？就是你自己搭的防护墙，结果被人家一根手指头就戳穿了，那种挫败感啊，简直了！不过好在后来我研究出了一套修复方案，今天就来跟大家唠唠这个CSP绕过的那些坑。

先说说是怎么发现问题的吧

那是个周五晚上,我正美滋滋地测试自己刚上线的网站，结果你猜怎么着？我的XSS payload竟然在CSP保护下成功执行了！我当场就愣住了，喝到一半的肥宅快乐水都差点喷在屏幕上，这怎么可能啊？我明明配了严格的script-src 'self'策略啊！

我赶紧去翻了日志,好家伙，原来是我的JSONP接口在捣鬼，你们想想看，我为了图方便，在script-src里加了script-src 'self' 'unsafe-inline'，这就等于把大门钥匙直接送给了黑客嘛！再加上我那个回调函数参数校验得跟闹着玩似的，不绕过你绕过谁啊？

修复方案CSP绕过的几个关键点

我得说句实在话,网上的那些泛泛而谈的“修复方案CSP绕过”的文章，看了等于没看，什么“严格使用CSP”啊，废话！我要的是具体怎么操作！经过那晚的折腾，我总结出这么几个实用的招数：

第一招：把'unsafe-inline'彻底干掉
一开始我是真舍不得扔掉这个特性，毕竟内联脚本用着方便啊，但你知道吗？黑客们最喜欢的就是这个口子，我后来改用nonce值的方式，给每个合法的脚本标签都生成一次性令牌，这招儿是真的管用。

第二招：别放过任何第三方资源
我之前纯属偷懒，对于外部域名的资源管控得特别松，结果呢？人家直接从我的分析工具脚本里做文章，通过那种反向的JSONP劫持方式就给绕了，修复方案CSP绕过必须要把所有子域、外部脚本都列白名单，一个都不能少。

第三招：千万不要忘了report-uri
这个真是血泪教训！我之前压根没配置内容安全策略的报告接口，就算被绕过了也是后知后觉，后来加上了report-uri，浏览器只要发现违规情况就会自动汇报给我，总算不用两眼一抹黑了。

真的，修复CSP绕过太难了

在测试那个修复方案CSP绕过的时候,我还经历了一件特逗的事儿，我自认为已经配置得密不透风了，结果最后一测，还是被绕了，你猜怎么着？原来是我限制了img-src，但是忘记限制redirect了！黑客可以用图片标签来发起请求，配合服务器端的302跳转，还是能把恶意脚本给引进来。

当时我真的是气得直拍大腿！但没办法，安全这玩意儿就是这样，道高一尺魔高一丈，不过别灰心，现在我的修复方案CSP绕过已经经过多轮测试，终于能睡个安稳觉了，我的经验是，一定要结合object-src 'none'、base-uri 'self'这些细节策略，形成一个完整闭环，光靠单点防御肯定是不够的。

修复方案CSP绕过的终极武器

现在我每次做修复方案CSP绕过测试,都会用上这几板斧：

动态生成nonce值,绝不静态写在HTML里
服务端强制校验Content-Type头，防止类型混淆攻击
用SRI（子资源完整性检查）来固定脚本的哈希值，一方被篡改，直接拦截

说到这里我还有点小激动呢,因为这招真的帮我挡了好几次攻击，记得有次，我用了一个第三方统计脚本，结果那家服务商被黑客黑了，刚更新个恶意脚本，马上就被我的SRI给拦住了，那种感觉真是舒坦！

我理解的CSP绕过本质

其实修复方案CSP绕过的核心,我觉得啊，就是要理解浏览器信任模型这个东西，CSP方案本来就是建立在“浏览器会严格执行”这个假设上的，但是只要你的策略配置里有一点点能被利用的间隙，浏览器就会按照它的逻辑去执行，这时候你就真的失控了，所以说，别把CSP当成万能药，它就是一个需要精心调教的工具，你得了解它的脾气，才能驾驭得住。