验证码的前世今生(前世篇)新.pdfVIP

验证码的前世今生 （前世篇 ） 常在网上晃悠的人 ，对上面这张图都不会陌生。特别 在注册新账号、确认交易时 ，它们都会频繁 出现 ，要求我们输入正确的验证码 ，那这些看上去跟我们要做的事情完全无关的验证码到底有何作 用呢 ？ 0×1诞生 首先 ，先介绍下验证码程序的提出者 ，路易斯·冯·安(Luis vo n A hn)。2002年 ，路易斯和他的小伙伴 在卡内基梅隆第一次提出了CA PT CHA (验证码)这样一个程序概念。该程序 指 ，向请求的发起方 提出问题 ，能正确回答的即 人类 ，反之则为机器。这个程序基于这样一个重要假设 ：提出的问题 要容易被人类解答 ，并且让机器无法解答。 在当时的条件下 ，识别扭曲的图形 ，对于机器来说还 一个很艰难的任务 ，而对于人来说 ，则相对 可以接受。yahoo在当时第一个应用了图形化验证码这个产品 ，很快解决了yahoo 邮箱上的垃圾邮 件问题 ，因此图形类验证码开始了大发展时期。 0×2发展与问题 图形化验证码在被证明有效后 ，在互联网上迅速得到了推广。国内外各大网站 ，在关键的业务点上 都加入了这一类型的验证码。 首先 ，由于开发者水平的良莠不齐 ，导致验证码本身的实现存在问题 ，从而导致漏洞可以绕过 ，常 见的有以下几种类型 ： [1] 验证码的生成逻辑、答案用户可见 如将验证码答案输出到页面中、写在coo kie里。打比方就 说 ，在发卷的时候 ，把答案写在了卷子 背面。(老师再也不用担心我的成绩) [2] 验证码的生命周期未控制好 如验证码可以重复使用、不设超时。验证一次 ，永久使用。 [3] 业务逻辑与验证码结合点存在问 如修改业务参数可导致不用校验验证码也可通过、甚至验证码就 摆设。结合到具体的业务点上有 什么危害呢 ？ a. 验证码写在coo kie中。此处可导致旅客信息泄露。 b. 验证码与图片存在对应关系 ，因此直接访问h ml即可得到答案。此处可导致撞库与暴力破解密码 。 （上述两例转自乌云 ） 0×3图片验证码对抗与攻击升级 在开篇我们提到了一个重要的假设 ： CAPTCHA提出的问题要容易被人类解答 ，并且让机器无法解答。 实际上 ，CA PT CHA所要处理的问题 ：将普通人与恶意的用户 （黑客、垃圾消息发送者 ）区分 开来。那当时间点到达2016年时 ，黑客们与普通用户之间的差距已经很大了 （想象下中国足球队对 巴西足球队 ，而且此时留给中国队的时间已经不多了 ）。 因此 ，CA PT CHA在图片验证码这一应用点上已经无法满足这一假设了。在这段时间内 ，出现了很 多的加强和识别图形验证码的方法 （每一种方法的详细原理和解释 ，可以参见wooyun dro ps ，在此 不做详述 ）： 附上部分名词解释 ： 如上图所示 ，原始的图像使用了字体旋转、背景色混淆等手段 ，在专业的验证码工具面前 ，也就 几个命令拼接即可完成识别 如上图所示 ， 一个验证码识别软件自建字库的过程 ，通过回车确认验证码识别正确 ，如有错误 ， 稍带修改继续。当保存了上千个正确识别的字库后 ，该程序便可达到一个可用的可用的准确率。 （ 其实若不不做其他限制 ，此时准确率在30%以上时 ，即可造成很大的危害 ，毕竟对于攻击者来说 ， 发3个包与发1个包的成本差别不大 ） 看到这里 ，客户们大概可以回答这个问题了 ： 为什么我用了验证码还 会被刷 ？ 那普通验证码难道没用了吗 ？ 那倒也不 ，安全 一个博弈的过程。综合使用之前提到的验证码技术(特别 字体粘连等) ，并且 保持关注和变化 ，攻击者的识别率也比较低。当攻击的成本大于可获得的利益时 ，自然就没人来攻 击了。 （普通用户在此应强烈要求存在感 ） 此时 ，虽然两方大小上略有差距 ，但 总体战斗力还算 勉强打个平手 ，互相出招而已。只 随着 战火的升级 ，个人轮番上阵后 ，验证码已经违背了他最初设计时的初衷 ：对普通用户的友好性逐渐 消失。而普通用户的体验也就成了这场战争中的牺牲品 ，这也就造就了一批有一批被用户吐槽的无 法辨认的验证码。 正当普通用户们不断吐槽的时候 ，程序员表示这个锅不想背但 也得背。因为业务总 要做的 ，而 攻击者们也 要吃饭的 ，升级了验证码的成本 ，也就限制了风险的等级 ，于 就变成了这样一个模 式╮(╯_ ╰) ╭ ： 程序员:熬一晚上升级 攻击者:熬一晚上破解 程序员:熬两晚上升级 攻击者:熬两晚上破解 (心疼)... 大家就在这种你方唱罢我登台的情况下看似和睦的度过了一段时间。