验证码安全基础

常见的验证码问题：

问题一：验证码是否出现的判断逻辑放在客户端浏览器

有些系统默认不显示验证码，而是在用户校验错误一定次数之后再出现。 那如何判断用户已经错误几次了呢？没有经验的开发可能这样做： 在cookie中写入一个标记，比如loginErr = 1，后续错误累加 在session中写入一个标记，例如loginErr = 1，后续错误累加 问题在于，要是恶意访问者不带Cookie提交HTTP请求呢？或者不更新Cookie中的loginErr的值反复提交呢？

程序因为无从获取Cookie/sessionID，会认为用户是首次访问。无论什么时候，验证码都不会出现！

问题二：验证码不过期，单个验证码反复可用

多数时候，验证码在web服务器上对应一个session值。

如果完成一次校验，不标记这个session已失效，就会造成同一验证码反复可用。

此时，验证码将不再有用。

恶意访问者在cookie中带固定的sessionID和固定的一个验证码字符串，即可轻松爆破。

还有一种很常见的代码实现，更新session的工作是通过重新下载验证码达到的。

而开发人员容易犯的一个失误，是把更新session的任务交给客户端浏览器。

比如302重定向，甚至是通过js、meta refresh重定向页面，来引导用户重新下载验证码。

这些做法实际是错误的，要是用户拦截了重定向，没有发出新的下载请求呢？ 这样，上次的验证码是否还可以使用？

基本的认知是：一个验证码，只能使用一次。使用之后，立即过期，不可再次使用。

问题三：将验证码内容输出到客户端

无论出于什么考虑，都不应该把验证码的内容发送到客户端cookie、或输出到response headers的其他字段。

比如，写入验证码的MD5值、 Base64转码等，太容易被逆向破解，得到原值。

即便是加固定salt后输出，都是很不好的。

问题四：验证码太弱

一般，出现逻辑错误的验证码，同样存在太弱的通病，使用开源的tessertact OCR引擎，不经任何训练，不人工去噪处理，也能识别互联网上的大部分验证码！