一、背景介绍
在业务安全领域,滑动验证码已经是国内继传统字符型验证码之后的标配。众所周知,打码平台和机器学习这两种绕过验证码的方式,已经是攻击者很主流的思路,不再阐述。本文介绍的是一个冷门的绕过思路和防御方案。这些积累,均来自于实战之中,希望有用。
二、思路介绍
知己知彼,百战不殆。
如果不清楚攻击者的手段,又如何能制定防御方案?
滑动验证码绕过思路漏洞名字:session参数重复校验漏洞
思路介绍:
此思路来源于一次对黑产路径的溯源复现,由于每次拖动滑块后,会发送一个Request请求数据包到服务器,服务器会验证这个Request请求数据包里携带的位移参数,来判断是否是拖动滑块到了正确的缺口位置。而服务器接收的数据包有很多,除了你发送的,也还会有其他人发送的请求,所以需要一个session参数来作为标识。本文中的”rid”值就是一个session标识。
其中”rid”值是加引号的,因为它只是一个参数。针对不同的滑动验证码厂商,可能参数命名不一样。
漏洞详情:
在用户客户端完成一次正确的验证码滑动后,发送到服务器的session参数,会在服务器后端,默认隐含生成一个有效时间和一个有效次数的值。前提条件是正确的滑动。想想这里会不会存在问题?
曾在黑盒测试中发现,有的滑动验证码厂商的后端逻辑设计存在缺陷,一个session参数的有效时间是10分钟,有效使用次数是5次。那么如何利用呢?这是我在风控后台的真实业务环境下,挖掘到的一条黑产绕过滑动验证码的手法。
思路剖析:
首先,触发滑动验证机制,如下图类似。
接着,滑动滑块到正确缺口位置,然后抓包。
分析数据包,寻找session参数。通过测试找到”rid”值为session参数。
这里再强调一下,不同的厂商开发的代码,可能对session参数命名不一样。比如下图,”sessionId”值是另一家厂商的session参数,需要我们去分析判断。
每次滑动正确位移后,使用Brupsuite或者其它中间人代理工具,抓包提取数据包里的session参数(”rid”值),保存到本地。
因为服务器后端默认隐含对我们本地保存的session参数有一个有效时间和有效次数,所以我们不需要再去滑动验证码,直接在session的有效期内发送Request请求数据包到服务器即可验证成功!
上述操作,我用python编写了一个小工具使其流程化。全自动化过程:调用打码平台滑动验证码滑块到正确位置,使用python的mitmproxy库配合正则提取rid,并写入保存到本地rid.txt。
最后黑产在实际批量注册,薅羊毛或刷赞过程中,遇到触发的滑动验证码机制,只要session在有效期内,只需使用python读取本地的rid.txt内容,调用requests库发送请求数据包,即可绕过滑动验证码。