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

滑动验证码js接口XSS攻击:

众所周知的跨站脚本攻击—XSS，攻击手法可能很平常，但把常用的攻击手法用在一个不被人注意的地方，有时候会给你意想不到的效果。

在某次实战中，对一个安全公司的真实后台登录页面做黑盒测试。

首先，给到的只有一个这种后台登录页面。

因为这家公司做的是业务安全，了解到这个后台是一个风控数据监测的登录后台。

风控面对的业务场景有：注册、登录、浏览，支付，活动等。

面对的威胁有：恶意爬虫、批量注册、薅羊毛、盗号撞库等。

风控策略有：限制注册登录频率、恶意IP识别、验证码等。

【恶意/正常行为】——【风控策略】——【业务场景】，风控在其中扮演者中间人的角色，无论是一个正常用户的行为还是群控设备的恶意行为，风控一方面会使用策略进行过滤行为，另一方面会将恶意/正常行为会被记录到日志中，进而在后台展示。

至此，信息收集完毕，我们整理一下思路。

我们先看一下手里拿到的测试页面，再对比分析一下上面那段信息。

我们发现这个登录页，是有滑动验证码的。而对比上面的信息，我将红色框圈出来的文字，构建了一个我的漏洞测试想法。如果我能控制滑动验证码的输入，那在后台的输出也可能将是可控的。红色框圈出的最后四个字，“后台展示”，第一反应就是用XSS攻击手法再合适不过了。

开始行动

首先，找到获取滑动验证码的js接口        

channel,appId,orgaization,lang,data,sdkver,callback,model,reversion

黑盒XSS——FUZZ

刷新验证码，截断，抓包。

蛮力碰撞，直接把所有的参数的值替换成XSS payload，但这样往往容易失败，因为有些参数是硬编码，一旦更改，服务器返回的respnse就会直接显示reject拒绝。

舍近求远，9个参数，抓9次包，分别替换参数值成XSS payload，最后，几分钟后，成功打到了cookie。

因为是黑盒测试，在漏洞修复后，内部人员把后台触发漏洞的位置告诉了我。

下面这张图是，风控后台的滑动验证码记录的行为信息展示栏，未修复之前这里有一列language的值，就是参数里的”lang”，而插入的XSS payload也就会出现在这个位置。