标签：完全 dash 引用 img 价格 学习交流 get 后端 防刷
0×01. 图形验证码
0×02. 短信验证码
0×03. 语音验证码
0×04. 滑动验证码
0×05. 总结
备注：无论使用哪种验证码，只要开发不当都可能存在安全漏洞，为了减少文章重复内容，只在短信验证码中讲解漏洞以及对应加固方案，在语音验证码中讲解风控预防措施。
图形验证码是出现最早也是使用最为广泛的验证码没有之一，从最早的简单验证码到现在各种五花八门的验证码，为了防止被识别有加噪点的，有加干扰线的，有加各种背景的，有加逻辑题的…
之所以会有越来越恶心的验证码主要是防止验证码被机器识别，所设计的验证码难度也在不断上升，相比较来看下面两张图就知道为什么会这么设计了。
一般识别流程:
一般验证码加固方法：
随着验证码难度的提高识别的成本也随即提高，为了进行识别测试，我分别收集了四家不同类型互联网公司的验证码，情况如下：
某招聘网站验证码 – 字母周围有噪点，字体扭曲
某电商网站验证码 – 不同样式，字母阴影，字母粘连，背景色干扰
某社交网站验证码 – 主体干扰线，背景色干扰，背景字母干扰，字体扭曲，字母粘连
某生活类网站验证码 – 背景干扰线，背景色干扰，背景字母干扰，字体扭曲，字母粘连，字体镂空
首先针对某招聘网站的验证码进行识别，这里基于tesseract写的一个OCR程序,测试样本10张，最后准确率在50%，反溯以下发现对识别相近字时会比较吃力比如”z”和”2″，”0″和”O”等等，因为验证码做了反识别部分验证码人眼也比较难识别，如果继续优化识别率达到70%左右应该问题不大。
接着对某电商网站的验证码进行识别，最后准备率在40%，由于该网站验证码难度各不相同对于这种类型的验证码比较难做统一处理，即使使用机器学习的方法一个模型也很难去识别所有的验证码。
后面两个网站的验证码使用图像识别去做难度就很高了，为了不被识别分别做了大量的反识别工作，那么对于这类验证码一般使用的是人工打码平台，之前有文章已经介绍过了这里就不重复描述了。
这是某打码平台的价格，网上可以找到很多类似的网站。
那么对于企业来说，怎么防止验证码被人工打码呢，从安全角度来说是比较难做到防止的，为了不失去用户体验每张验证码的失效时间并不会很短，对于一个熟练的人工打码人员来说完全不在话下，那么我们从验证码本身出发去提高攻击的一个成本，举一个例子，可以使用DataURI scheme的方法把验证码图片直接写到HTML文件中去增加识别的时间和成本，当然还会有很多方法可以去增加攻击成本。
如果想从根本去除打码平台的困扰，这里可以参考支付宝和微信这两个产品的验证码机制，在某些地方所弹出的图形验证码是和使用者有关，比如选择联系人头像，选择购买过的物品，对于人工打码的人来说是完全不知道答案的，但是用了这种类型的验证码也会出现问题，比如“好友”足够了解你的情况下（个人信息泄露太多）可能会成功的进入。
现在有很多文章会用到神经网络CNN的方法用来识别验证码，相比传统的识别用机器学习有了样本的学习，识别率会更加的准确，对一些人眼可能判断错误的字母机器或许能判断准确，不过学习成本也是很高的。
短信验证码常见于注册，忘记密码，确认下单等阶段，特别是一些涉及到用户个人敏感行为时候，为了确认操作是用户本人执行的通常会使用短信验证码进行二次认证。同时，短信验证码也是最为常见的验证码类型之一，这里总结一些验证码逻辑漏洞。
起因：短信轰炸问题往往出现在一些小站或者子站，这几年很少看到通过GET请求发送短信验证码了，基本都是使用POST请求，使用抓包软件可以重放请求对于后端没有做限制的网站就可以达到短信轰炸的效果。
危害：对用户来说个人生活受到骚扰，对企业来说造成一定的负面影响，很多小公司因为短信接口被大量调用出现运营问题，对于公司没有安全工程师的情况下，一般都是业务方发现了数据异常向上汇报，最后和开发一起反溯才会找到这个问题，那么在这段时间中对企业所损失的钱也是无法挽回的。
预防：这里主要是针对两种攻击场景来进行防御，第一种是对单用户的短信轰炸，即重放发送请求且phonenum为一个值。第二种是对多用户发送短信骚扰的场景，即将phonenum参数设置为字典，重放短信接口。
设置发送间隔，即单一用户发送请求后，与下次发送请求时间需要间隔60秒。
设置单用户发送上限，即设置每个用户单位时间内发送短信数的上限，如果超过阈值就不允许今天再次调用短信接口（阈值根据业务情况设置）。
设置单IP发送上限，这种情况是预防第二种攻击场景的，由于IP的特殊性可能存在所处IP是大出口，一旦误杀后果会很验证，所以这个限制根据自身情况酌情考虑，对于有风控的团队来说，当发现发送IP存在异常可以对该IP增加二次认证来防止机器操作，也可以降低误杀情况。
备注：b和c两个漏洞场景一般截图说明下开发就知道问题所在了，这里修复建议的内容写的就比较少。
起因：因为开发不严谨导致通过抓包可以看到验证码在回显中显示。
危害：由于验证码直接返回，通过该漏洞可以注册任意用户，重置已注册用户密码，修改绑定信息等高危操作，对用户造成一定影响。
修复建议：不要将短信验证码在回显中显示，验证码只存于服务端中并不能通过任何api直接获取。
起因：前端校验导致下列问题。
危害：可跳过正常校验逻辑。
修复建议：服务端严格做检验，和开发谈谈心。
假设网站验证码接口没有以上说的任何漏洞，那么短信认证是否安全呢？
在用户手机没有被种木马，用户手机没被强制降频到GSM等情况下，当攻击者无法获取短信验证码则某些关键操作是无法继续的，在一定程度上起到了拦截的作用。特别针对盗号的场景，由于设备或常用地发生了变化，在用户登录时候弹出验证码进行校验防止被盗号的情况。短信验证码只对部分场景可以起到防护作用，单一的认证对于企业来说无法阻止以下的场景。
这张图在我上一篇文章中出现过，这是在某打码平台注册了一个帐号的截图，从图上就可以看出虽然用了短信验证码，但是可以通过打码平台来自动获取并完成注册流程。
针对打码平台的垃圾注册场景也可以通过一些手段去增加批量自动化的注册成本，防御手法有相同之处，在语音验证码中会简单讲解。
相比短信验证码，语音验证码存在以下的优势：
a.语音验证对防刷单效果更显著；
b.语音验证码到达率更高；
c.用户体验更加友好；
为什么说语音验证码对防刷单更有效，这里贴一张某打码平台的收费情况，可以看到语音验证的价格是短信的十倍。很多公司是不会对17开头的虚拟号段进行发送的，为此卡商提供的卡号基本是实名认证的且没有停机的正常号段，所以收语音验证的成本就会比短信高很多。
这家打码平台对语音识别有两种方式，一个是系统识别，另一个是自己听取，对于系统识别平台解释是由听码团队负责听取验证码后传输文字回来，自己听取则是自己下载语音验证码录音自己听候识别。
跟公司研究移动端安全的小伙伴讨论了下，根据目前的技术要做到全自动也并非不可能，这里简单画了一个流程，从触发语音认证开始到最后的填入完成验证一条龙。
首先要获取语音认证，等语音验证码说完以后自动保存录音，进行语音分析，国内有几家厂商有语音识别的服务并都提供SDK，所涉及的服务可以用来进行识别，将语音转换成文字并提取验证码部分，完成最后验证。
对于企业来说我们如何防止这种垃圾注册的场景呢，说几种通用的思路供参考，这里主要可以分事前和事后基于规则和行为做判断。
对于事前，可以借助反欺诈接口检测请求的号码是否存在风险，WEB端判断用户UserAgent是否存在异常，APP端判断用户DeviceID是否存在异常，由于事前可以拿到的信息并不多，可以围绕可以拿到的参数做规则，对触发规则的用户进行阻断操作，可以在发送短信或者语音前让其先填写一次图形验证码，多一步校验。当然，也有公司会将部分手机号进行拉黑操作，在源头上禁止某些手机号进行注册。
对于事后，服务端校验以后就可以拿到状态等信息，围绕这些信息又可以制定一些规则，这里可以举一个通用的规则，比如单位时间内单IP登录失败超过阈值的对这个IP进行某某处理，这也是最基本的频次规则。对于不同的业务有着自己不同的策略，比如金融公司的APP会索取用户通讯录的权限，根据用户的好友做用户画像，某些公司也会做二度关系画像来判断用户是否存在风险。
这里不会说太多的规则和策略，由于公司的业务都不尽相同，当日志接入以后针对目前场景存在的问题去设计不同的规则即可。
现在有不少的互联网公司开始使用滑动验证码进行校验，看似一个简单的滑动操作，背后都有风控引擎和相应的规则作为保障，首先讲一下滑动验证码的整个流程。
我们说一下正常的逻辑，首先用户滑动验证码到指定位置，完成后会给服务端回传各种加密信息，为了做风控规则来判断是否异常，个人猜测其规则会包含用户IP，操作行为路径，UA,COOKIE，设备指纹等等，如果没有命中规则，就会放行校验通过，如果命中规则就会弹出二次校验，只有通过校验后才可以放行。
那么如何破解滑动验证码呢，第一种是模拟正常用户操作，并让风控不要命中风控规则。第二种是尝试破解第二阶段的验证，对于图片可以使用OCR技术进行识别（针对类ReCAPTCHA验证码）。第二种的难度比较高，网上的文章也是针对第一种来进行破解，这里简单讲一下破解方法。
我对某商业滑动验证码进行了测试，整体流程梳理如下：
全部过程可以用自动化来实现，整体成功率要分为两个部分来看，第一是验证码自身风控能发现多少问题，我所测试的接口破解成功率在76%左右。第二是企业自身的风控规则能发现和阻断多少异常情况。两者结合最后的成功率就会有所下降，虽然有接口破解但是价格昂贵，已经提高了攻击成本，如果账户不涉及到金钱也不会考虑这么高的攻击成本，其实说到底还是成本和收益的一个衡量。
这里聊一下商业化滑动验证码厂商的优势和弊端。首先说优势，滑动验证码肯定会成为一种流行趋势，对于企业来说自研的成本比较大，无非也就是几个工程师参考已有的进行模仿，先不说效果开发流程上就会耽误人力，这点钱宁愿使用商业化的，现在的产品都已经相对成熟也有专门的团队进行升级维护，安全和体验性上来说都还不错。弊端到也谈不上，这里主要说几点使用前要考虑的地方，一个是响应延迟，当大量并发过来的时候是不是撑得住，最高响应时间是否有上限，如果超过是否会降级，如何降级等等，万一碰到不可预计的问题，比如碰到光缆被挖断，服务是否能即使切换，灾备是否完善等等，在购买前这些问题最好都要进行测试并有应急方案。
前面也总结了很多验证码，我认为一个好的验证码首先不能有逻辑上的漏洞能绕过，否则再复杂的验证码都是形同虚设。其次，不能为了增加破解难度而抛弃用户体验，不要把验证码做的极其复杂人眼都识别不了，这种也会失去验证码的意义（用户都没了还给谁验证…）
目前来说大部分的企业还是偏向使用图形验证码，在测试过程中只有极少数的公司会动态升级自己的图片验证码，随着输错次数的上升验证码难度也随机上升。统一验证码的设计初衷是好的，即使攻击者使用了OCR技术进行破解，一旦失败数触发到阈值即自动上升图形验证码难度，增加破解成本。
为了防止验证码被爬虫获取后专门进行分析，针对性的破解攻击，需要准备多套图形验证码定期进行替换。
统一验证码体系如果只用单纯的规则去匹配所弹出的验证码，那么这种情况会出现不少的误杀，会让某些正常用户操作频次超过设定阈值，用户在尝试输入密码的过程中验证码越来越难，最后导致用户投诉。所以我认为一个完善的统一验证码体系应该由风控来判断是否触发规则，对触发规则的请求进行相应的验证升级，而不是设定一个死的阈值，对关键操作可以用多种验证码组合的形式来进行校验，常见的组合有，滑动+图形，图形+语音等。
就我个人而言，比较喜欢点触式和滑动式的验证码，通过采集用户当前各种的参数行为（行为轨距，操作时间，当前环境等等）来判断是否为机器行为。在用户体验上，手机端不是很建议使用选字类型的验证码，对于非大屏的手机不是很友好。在安全性上，这类验证码要比其他验证码破解成本高。我相信验证码的趋势也会逐渐向这种类型的靠拢。
下面的图片引用了google的ReCAPTCHA，分别截取图片和语音验证，ReCAPTCHA在安全性和用户体验做的都很好，即使这样还是被安全研究者破解过，所以不要完全依赖一种验证码，对敏感操作可以使用多种验证码。下面是官网的DEMO：
图片类：
声音类：
无论哪种验证码都有自己的适用场景，也没有一种绝对安全的验证码，根据自身业务情况来选择对应的验证码类型，在用户体验和安全性中找到属于自己的平衡点。最后，有做业务安全的同学可以一起学习交流。
标签：完全 dash 引用 img 价格 学习交流 get 后端 防刷
原文地址：https://www.cnblogs.com/wjw-zm/p/11831245.html
