本文目录导读：
CSP绕过RASP防线？别慌，咱们聊聊黑客的这波骚操作
哎哟我去，兄弟们，最近后台有粉丝私信我，说他们在实战测试的时候，碰上了RASP（运行时应用自我保护）这堵墙，撞得头破血流，问我有没有什么“骚姿势”能绕过去，啧啧，说实话，这问题问得我心里直痒痒，我今天就豁出去了，跟大伙儿唠唠这个CSP绕过RASP防御的实战思路，先说好啊，这是技术研究，咱得守规矩，别拿去干坏事，不然我诅咒你写的代码全是Bug,哈哈哈。
先搞清楚，RASP那哥们儿在防啥？
咱先打个比方，RASP就像是你家请的一个贴身保镖，不是站在门口那种（那是WAF），是直接住你代码里、盯着你业务逻辑每一行执行的那种，你传个参数进来，它得看看你是不是图谋不轨；你调个函数，它得闻闻有没有危险的味道，哎，说白了，它就是靠行为分析和上下文感知来拦截攻击的，针对性极强，确实挺烦人的。 安全策略）呢？这玩意儿本来是个“良民”，是给浏览器看的，主要防XSS，告诉浏览器哪些资源能加载、哪些脚本能执行，按理说，CSP和RASP一个管前端浏览器，一个管后端应用，八竿子打不着啊？嘿嘿，但聪明绝顶的黑阔们（对，就是咱们这些搞安全的），总能找到它们俩之间的“化学反应”。
灵魂拷问：CSP怎么就能扯上RASP了？
重点来了啊，大伙儿注意听。CSP绕过RASP的核心逻辑呢，其实不是直接去硬刚RASP的检测引擎，而是利用CSP的配置或实现缺陷，去破坏RASP赖以生存的“情报来源”。
你想啊，RASP再牛，它的判断依据很大程度来自于请求的数据流和函数调用栈，而CSP控制着页面资源的加载和脚本的执行，假如我们能通过某种方式，让CSP策略失效或者被绕过，从而注入一个外部的恶意脚本（用于模仿正常请求逻辑、混淆数据流），那你这个恶意脚本的请求，在RASP看来，行为特征和上下文信息就跟你自己正常前端JS发起的请求是一样一样的，RASP一看，诶，这数据流很干净啊，放行！你看，这不就利用CSP把RASP给蒙混过关了嘛？
再举个接地气的例子，有些站点的CSP配置得跟筛子一样，比如用到了unsafe-inline或者不校验script-src，那我们就能直接往页面里注入一段JS，这段JS不是直接去弹窗（那太low了），而是去模拟正常业务逻辑，比如修改前端参数、重置会话时间戳，RASP在检测的时候，看到的是拼接过来的“正常”业务操作，压根儿不会往攻击方向去深挖，啧啧，这套路，属实是“借刀杀人”啊！
实战中的“骚姿势”：具体怎么操作？
这么跟你们说吧，我复盘过一些案例。CSP绕过RASP的姿势往往分这几步走：
- 探路子：先看响应头里的CSP字段，看看是否有
script-src的宽松配置，或者有没有jsonp接口能用来当作CSP的“合法兵工厂”。 - 找“小三”：寻找一个允许外部加载的域名，最好是可控的，比如
*.cloudfront.net或者开启了CORS的静态资源站。 - 搭“桥”：利用CSP的宽松政策，把我们的恶意脚本或者数据加载指令，伪装成“信任域”的资源,成功注入。
- 偷天换日：注入的脚本开始跟后端正常通信，但携带的payload已经经过了特殊编码，能规避RASP的关键字检测（比如把
select拆成sElEcT或者用Unicode混淆）。
这一套下来，RASP其实是在哼哧哼哧地分析“正常流量”，而咱们的攻击指令早就在它眼皮子底下“瞒天过海”了，哎哟，想到RASP那哥们儿事后复盘时一脸懵X的表情，我心里就莫名想笑，哈哈,太贱了！
写在最后的话（掏心窝子的）
说真的，CSP绕过RASP这玩意儿，玩的是逻辑思路，考究的是对前端安全策略和后端运行时机制的深入理解，它不是让你拿工具扫一下就能出了，得静下心来分析业务逻辑，学这玩意儿，头发掉得快,但成就感也是真的强。
行了行了，今天关于CSP和RASP之间的这点爱恨情仇，咱就聊到这儿，我这也是抛砖引玉，如果你有更刁钻的绕过姿势，欢迎来下面评论区跟我抬杠，我保证不删你评论（除非你骂我丑）。
最后最后，老规矩，下面那个QQ号是我小号，平时我就在群里分享些技术干货，有啥不懂的、想深入聊聊安全的，或者单纯想找人听听你牛X事迹的，都可以加一下，注意，加的时候备注“安全交流”，不然我不通过的哈！咱们群里见！
网络安全学习交流群：123456789（纯手工打字，不是机器人）
