验证码的几个常见裂痕

把验证码存储在Cookie中

一样平常来说，我们会把验证码的值用Session存储起来，通过比拟用户提交的验证码和Session中的验证码，就可以知道输入是否正确。因为Session会占用处事器资源，我曾经想过是否可以把验证码的值加密后存储在Cookie中。不外究竟证明，这只是异想天开而已。

假设验证码的值是a，通过sha1加密后获得的值为b = sha1(a)，而且把b存储在Cookie中。而用户提交的验证码值为c，通过判定sha1(c)是否与b相称，可以知道输入的验证码是否正确。然而，Cookie是受客户端节制的。假如用户事先通过肉眼看到验证码的值是a，又从Cookie中得知此时的加密值为b，那么，他只要在提交前把Cookie的值修改为b，提交的验证码值为a，就可以永久通过验证。

没有举办非空判定

这种环境可以直接用代码来声名：

if (Request["captcha"] == Session["captcha"] as string) 
{ 
 // 验证通过，继承操纵 
} 

假设用户绕过了体系提供的表单直接提交数据，此时验证码还没天生，Session["captcha"]为空。用户不提交验证码时，Request["captcha"]也为空。于是，验证通过了。

要办理这个题目，着实只要加个非空判定就可以了：

if (!String.IsNullOrEmpty(Request["captcha"]) && 
 Request["captcha"] == Session["captcha"] as string) 
{ 
 // 验证通过，继承操纵 
} 

没有实时烧毁验证码

行使验证码要遵循一个原则，在一次比对之后，无论用户输入正确与否，都要立即将验证码烧毁。

假如不这样做，就可以呈现以下环境：

• 假设用户输入错误，且验证码没有从头天生，那么他就可以一向实行，直到正确为止。固然呆板对图片的一次性辨认率较量低，可是，假犹如一张图片你给它无穷次机遇的话，它照旧可以辨认出来的。
• 假设用户输入乐成，且验证码没有烧毁，那么在Session逾期之前，他就可以一向用这个验证码通过验证。

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!