转载

打造双剑合璧的 XSS 前端防火墙

前言

深入接触xss 注入是从排查业务的广告注入开始，以前对xss 注入片面认为是页面输入的安全校验漏洞导致一系列的问题，通过对 zjcqoo 的《XSS 前端防火墙》系列文章，认识到自己其实对XSS 注入的认识还真是半桶水。

捣蛋的运营商

由于xss 注入的范围太广，本文仅对网关劫持这一方面的XSS 注入进行讨论。

这里读者有个小小的疑问，为什么我要选网关劫持进行讨论？因为网关劫持可以大面积范围进行有效控制。

曾经，有这样一道风靡前端的面试题（当然我也现场笔试过）：当你在浏览器地址栏输入一个URL后回车，将会发生的事情？其实本文不关心请求发到服务端的具体过程，但是我关心的时，服务端响应输出的文档，可能会在哪些环节被注入广告？手机、路由器网关、网络代理，还有一级运营商网关等等。所以，无论如何，任何网页都得经过运营商网关，而且最调（zui）皮（da）捣（e）蛋（ji）的，就是通过运营商网关。

另外，也提醒大家，如果手机安装了一些上网加速软件、网络代理软件或设置网络代理 IP，会有安全风险，也包括公共场所/商家的免费 WIFI。

前端防火墙的实践

经过近一段时间通过对 zjcqoo 的《 XSS 前端防火墙》六板斧的反复琢磨理解，基本上防御措施可以归为两大类：一种是从协议上屏蔽，一种是从前端代码层面进行拦截移除。通过 zjcqoo 提出的几种注入防御方式，进行几个月的实践观察，对广告注入方式大概可以归为两种：完全静态注入、先静态注入后动态修改（创建）。

1. 完全静态注入

完全内联 js、css、和 dom，不管是 body 内外，甚是恶心，而且如果是在监控脚本前面注入的，还可以抢先执行，造成防御不起作用。注入的 DOM 也无法清除。

2. 先静态注入后动态修改

这种可以分为几种：一种是异步请求接口数据再生成 DOM 注入，一种是修改 iframe 源地址进行引入，另外一种是修改 script 源地址，请求执行 js 再异步获取数据或生成 DOM。

监控数据观察分析

对 zjcqoo 提出的几种防御方式的实践，前一个月主要是花在优化检测脚本和增加白名单过滤脏数据方面，因为这块事情只能利用业余时间来搞，所以拖的时间有点久。白名单这块的确是比较繁琐，很多人以为分析下已知的域名就 ok 了，其实不然，云龙在这篇 iframe 黑魔法就提到移动端 Native 与 web 的通信机制，所以在各种 APP 上，会有各种 iframe 的注入，而且是各种五花八门的协议地址，也包括 chrome。

监控拿到的数据很多，但是，由于对整个广告注入黑产行业的不熟悉，所以，有必要借助 google 进行查找研究，发现，运营商大大地狡猾，他们自己只会注入自己业务的广告，如 4G 免费换卡/送流量/送话费，但是商业广告这块蛋糕他们会拱手让人？答案是不可能，他们会勾结其他广告代理公司，利用他们的广告分发平台（运营商被美名为广告系统平台提供商）进行广告投放然后分成...

对于用户投诉，他们一般都是认错，然后对这个用户加白名单，但是他们对其他用户还是继续作恶。对于企业方面的投诉，如果影响到他们的域名，如果你没有确凿的证据，他们就会用各种借口摆脱自己的责任，如用户手机中毒等等，如果你有确凿的证据，还得是他们运营商自己的域名或者 IP，否则他们也无法处理。他们还是一样的借口，用户手机中毒等等。

除非你把运营商的域名或 IP 监控数据列给他看，他才转变态度认错，但是这仅仅也是之前我们提到的流量话费广告，对于第三方广告代理商的广告，还是没法解决，这些第三方广告代理商有广告家、花生米、XX 传媒等等中小型广告商，当然也不排除，有的是“个体户广告商”。

[1] [2] [3] 下一页

正文到此结束