图形验证码常见安全风险

陈金宝

微信号

功能介绍

从今天起，搜狗安全知识学堂开课啦！本课程将以连载的形式，尽量以浅显易懂的语言向大家讲述一些安全方面常用的知识。

欢迎各位小伙伴积极参与交流。

       第一讲内容我们介绍一下开发人员在防范机器自动化行为中最喜欢使用的组件——图形验证码。

背景

在各种业务系统中，无论是web端，还是移动端，图形验证码一直被认为是一种非常有效的分辨人和机器行为的方式。它在防刷、防暴力破解等领域发挥了巨大作用。当然，他的劣势其实也很明显，就是比较影响用户体验。

但是，设置了图形验证码就真的安全了么？其实，图形验证码设计不当，不但影响用户体验，而且也无法达到屏蔽自动化行为的作用。经过小编多年的经验，本文从几个方面来讲述图形验证码可能存在的风险。

图形验证码风险点

OCR识别

OCR(Optical Character Recognition，光学字符识别)肯定是要首先提到的啦。通过图像识别技术，可以把图像中的字符识别出来，并转换为文本。要不是因为这项技术，铁道部12306也不会搞出那么逆天的验证码了。作为开发人员，如果想要你的验证码安全，就要尽可能的让字符做一些特殊处理，比如删除线、字符倾斜、模糊处理、粘连、增加噪声等等。但是呢，如果太复杂了，可能真正的人类也无法很好的识别了。这真的是个很纠结的场景。本文对OCR技术不做过多描述。

验证码本地验证

一些开发人员在验证码防范的原理上没有搞清楚。为了开发方便，搞了个通过web前端进行校验。这其实失去了验证码的意义。个人认为，这种不合理的方式通常分为两种：

1. 验证码在本地cookie中明文填写

开发人员为了规避分布式会话的问题或为了方便校验，将验证码直接使用了本地校验的方式。这种实现方式是有明显缺陷的，恶意人员可以直接编写代码从cookie中取出验证码，甚至绕过验证码的验证。

<图一>

   b. 验证码与提交的表单内容并不一起提交

这个问题纯属设计上的问题。在用户输入了验证码之后，页面发送一个验证图形验证码是否正确的请求到服务端（如图2所示），服务器端会返回true或false（如图3所示）。若为true，前端界面认为你的验证码是正确的，就可以点击按钮进行提交了。但是大家可以仔细看下图4，最后的表单操作并未提交验证码，也就是说。其实恶意攻击者只需要抓取图4中的表单提交的请求地址，构造相应的post请求，就可以进行暴力破解等操作。这个图形验证码设计的毫无意义。

<图二>

<图三>

<图四>

验证码为文字形式展示

这种风险出现在早期的系统中。开发人员为了方便，验证码为文字形式，而不是图片形式。因此恶意人员其实可以直接通过页面代码获取到验证码的明文内容

验证码重复使用

这个问题主要源于验证码使用一次之后，服务端未能及时对session中的验证码做失效或更新处理，造成恶意攻击者可以使用同一个sessionid，配合相同的验证码重复使用。使验证码被成功绕过。

逻辑验证码真的安全吗？

前几年流行过所谓的“逻辑验证码”。在逻辑验证码当中，数10以内加减法运算题居多。可是大家可以想想。通常无论题目多么复杂，结果都是10以内的数字。因此，理论上来说每次猜对验证码的概率都有10%左右，并不算低。再加上之前遇到一个系统，由于在提问问题生成的算法上不够随机，导致问题答案为0的情况非常多，能达到50%以上。因此恶意攻击者把验证码设置为0，成功的概率就会很高。

总结

由此可见，小小的图形验证码，门道还真的不少呢。要想安全、合理的使用它，还真的需要开发人员多动些心思。

本期的安全知识学堂——图形验证码常见安全风险就到这儿啦！

下期会给大家说说短信验证码和邮件验证码可能存在的安全风险。

敬请期待~

若你有

技术交流、吐槽、投稿、领红包等行为请扫如下二维码

请相信它将是你进化的一个方向