网页验证码的基本原理、常见漏洞及解决方法

    前些天查了一些验证码的资料，了解了一些信息，也发现了一些网站确实存在的漏洞。下文将分析验证码原理及存在的问题。首先声明：本文仅仅探讨技术，请各位读者不要利用这些信息进行非法行为，笔者不承担任何连带责任！当然，笔者能力有限，这里也提供不了什么实质性技术，只是将自己获取的一些信息与大家分享，呵呵。
    验证码的原理其实比较简单，一般都是链到一个动态页面，然后后台服务器生成一个随机数，利用这个随机数映射一张图片，最后将这张图片返回客户，同时将这个随机数保存起来，当用户提交验证码时检测填写的验证码是否和这个随机数相同。这里我想重点说三点，这三点处理不好都可能被破解者利用。一是随机数的生成，二是随机数和图片的映射，三是随机数如何保存。
    随机数的生成是第一个需要注意的问题。大部分网站采用的都是伪随机数生成算法，而目前的伪随机数生成算法种类不多，编写验证码代码的人如果算法功底不强(或者偷懒)，往往都采用后台语言类库所提供的伪随机数生成算法，这样从算法的角度入手破解的可能性还是比较大的。但是由于破解者往往数学功底也一般所以被破解的可能性也有限，但是一旦被破解验证码也就形同虚设。笔者算法功底也一般，在此不做深入研究，建议采用优良的随机数生成算法。
    随机数和图片的映射问题，我所了解的有两种。一种是将所有验证码图像以二进制形式存储在数据库(或文件系统)中，实现时根据生成的随机数将对应的图片取出即可；第二种是根据随机数实时的生成一张图片，然后返回(当然，为了提高效率会加入服务器端缓存策略)。第一种方式比较健壮，因为可以在图片上加上很多噪音，第二种方式就比较危险，主要看你生成图片的算法如何了，如果不好的话很容易被破解。这里的典型破解方式是利用图像识别技术分析显示的图片。如果图片是通过第二种方式生成的就很容易被识别出来，现在手机上的手写技术就是一个典型的例子。但是如果采用第一种，预先在每张图片中加入大量噪音，识别率还是很小的。
    随机数的保存问题看似简单，其实是最容易被破解者利用的。很明显，随机数是与会话密切相关的，以.NET为例，保存方式无外乎有三种：一种是采用Cookie，将验证码加密(可以采用优良的加密算法在后台完成)然后写入客户端Cookie中；第二种是Session，直接将随机数保存到某个会话变量上；第三种是Application，将随机数保存到全局变量中。由于这个问题比较脆弱，也很容易别利用，下面重点分析。
    保存在Cookie中其实是很危险的一种做法。虽然可以在后台将随机值加密后再保存到Cookie中，但是却为破解者进行重放攻击提供了一条途径。比如说验证码是1234，用户通过看图片肯定知道是1234，此时Cookie虽然没有直接保存1234，但却保存了1234对应的密文，而这个密文是直接可以获取的。这样用户就知道验证码1234对应的密文是什么。如果下次再出现这个密文就可以立即知道对应的密码是1234。这样只要破解者有足够的耐性就完全可以进行重放攻击。
    对于.NET来说，保存在Application中和Session中类似。如果保存在Application中就需要采用某个标识来区分不同的会话，这个标识当然是非SessionId莫属了。Session的实现原理这里就不多说了，.NET允许将Session数据保存在服务器端和SQL SERVER数据库中，对于SessionId的保存可以在Cookie中，也可以设置成Cookieless通过虚拟目录解决。对ASP来说，漏洞要多很多，首先页面和代码是混合的，如果获取了后台的读权限就可以知道所有细节了，另外它的SessionId不支持Cookieless，只能保存到Cookie中。如果一个验证码是通过ASP实现的，那破解者完全可以通过ASP自身的问题破解。这里侧重分析各类实现均存在的通用问题。这样，后台的验证流程是：会话开始->生成回话编号[可能保存在客户端]->生成随机数->获取随机数所映射的验证码图片->保存随机数[保存在服务器端，利用回话编号和变量名访问]->客户端显示验证图片->用户填写验证码->数据提交到后台[含会话编号]->后台根据回话编号和变量名取出保存的随机数->验证是否正确。
    一间事务所经过的环节越多，出现问题的可能性就越大。这个验证流程中可被破解的地方理论上也很多，但是破解这个流程的难度等同于破解Session机制。当然，这个破解Session机制可能是直接的[难度相当大]，也可能是间接的，[如非法访问Web服务器，非法访问Session保存数据库等]。然而还有一个更容易破解也很容易解决的问题。这个验证流程虽然已经比较长了，但其实还不完整。由于HTTP一次回应只能是文本或者图片等二进制数据，不能同时包含，这样验证码图片的获取和操作页面的获取就必然是两次HTTP请求。也就是说请求操作页面和请求验证码图片的操作不是原子的。这样，如果用户第一完整的请求了操作页面和验证码图片，以后就只请求宿主页面不再请求验证码图片，这样验证码就永远维持在第一次显示的验证码了。这样就为一些含验证码网页的暴力破解提供了一种可能。
    就总结到这了。从中至少可以看出——网页验证码的设计还是需要仔细斟酌的，如果设计不好，还是很容易出现瑕疵的，呵呵。