实战笔记：滑动验证码攻防对抗(3)

最后，在黑盒测试盲打XSS中，很大一部分靠运气。但使用极限语句再配合一个超短域名的XSS平台，会增加成功率。

攻击手法总结

从黑产/攻击者的角度，针对滑动验证码，我们介绍了一种绕过的思路：session参数重复校验漏洞，一种攻击的手法：JS接口的XSS攻击。

那么，从风控/防御方的角度，我们如何制定防守方案呢？才疏学浅，不敢无稽之谈，只能把平时实战之中碰到的问题，记录下来，希望有用。

被动防守——针对攻击者

这里没什么特色，既然是被动防守，自然是要避免亡羊补牢。针对诸如XSS等OWASP TOP漏洞，不能依赖开发的细心。除了在业务上线之前，内部测试和攻防测试；还可以在在业务上线之后，托管类似国外Hackone平台的国内赏金平台，或自运营SRC。当然，结合考虑预算成本。

主动出击——针对灰黑产

主动出击，针对的是利用滑动验证码，来精准识别灰黑产。

在上一篇文章实战笔记之X厂滑动验证码漏洞挖掘里最后一节，提到了多缺口、滑块多样化的方案。

在一次滑动验证码更新升级过程中，发现了一个新思路。

原始过程：在用户完成一次验证码滑动后，将request请求数据包发送给服务器。

升级方案：在服务器后端升级滑动验证码的js代码，使每一个滑动验证码都在用户客户端生成一个或多个随机参数，这些随机参数需要跟随request请求发送到服务器进行一个简单逻辑验证。重点在于：正常用户只有通过滑动滑块发送的request数据包才一定是携带随机参数的，但并不强制要求发送的request请求携带这些随机参数。

精准识别：因为核心圈的黑产下放的工具，都是通过直接通过发送request请求数据包来进行批量注册、刷量刷赞和恶意爬虫等行为。称之为：“协议刷”或“打接口”，这种方式效率极高。加上利益化的原因，黑产不会去在乎过程，只在乎是否结果能成功。

升级的方案：只有通过正常滑动滑块，才能发送携带随机参数的request数据包发到服务器。

旧方案：通过以前的旧接口直接发送不携带随机参数的request数据包到服务器也可以通过验证。    

在无声无息升级后，两种方案并行运行，那么拐点就到来了。

是不是就意味着旧方案的验证码接口过来的ip，sdk，captcha_flag等数据一定都是源于黑产池；而升级方案的验证码接口过来的ip，sdk，captcha_flag等数据不说百分百，也绝大部分都是来自正常用户群体。这就悄然无声的就达到了精准识别灰黑产的目的。    

持续化：在被黑产发现后，就需要做持续化更新的对抗了。

还是那句，攻防本身就是一场不公平的战斗，或许只要能大大增加黑产攻击者的成本，就是有效果的防守。

以上理论，皆为实战总结。希望有用。

如果没有，我想下篇或许会有。