表单验证多种方案分析

（一）表单验证码：

目前网站流行的验证码机制，基本上都是通过服务器端 Session 来实现的，其工作流程描述如下：

1.用户访问提交数据的表单页面时，服务器会生成一个随机串，保存在服务端的Session中;

2.将上一步生成的Session以图片的方式展现给用户，图片上的数字和字母就是“验证码”，用户提交数据的时候，需要将验证码内容一并提交;

3.系统在接收到用户提交的数据时，先验证用户输入的“验证码”是否和Session一致;

4.如果不一致，说明是非法请求，则可以直接拒绝掉该次请求。

验证码机制的弊端列举

“验证码”产生的背景是为了避免网站受到恶意的请求，出发点是好的，但是验证码的方法将“避免网站受到恶意请求”的成本转嫁给了用户；

用户不是在看页面，而是在扫描。验证码相对于整个页面来说，是完全附加给用户的无用信息。应该尽量避免用户思考，这是用户体验的基本功；

由于验证码每次的产生的数字是随机的，而且生成的验证码为了避免被机器识别，通常会加上一些防识别的干扰字符，通常情况下，这会增加用户识别和输入的成本，给用户造成挫败感，导致用户流失。

验证码机制优化

更改验证码出现的频率：

这种方案是一种折中方案，即默认情况下不显示验证码，仅当用户输入的错误次数大于指定次数的时候，服务端才认为该请求有可能是恶意请求，同时加入验证码的验证机制。目前 Google、Yahoo均是采用本方案。Google允许的出错次数是3次，Yahoo是5次。

优点：90%以上的用户不需要输入验证码，即保证了验证机制的安全，又有效的将验证码对用户体验的影响降到最低;

缺点：最终还是靠验证码来实现，不够完美。

(二)使用SSL协议加密处理：

SSL全称是Secure Socket Layer，是被设计用于WEB的安全传输协议。目前该协议在WEB上获得了广泛的应用。此方案的工作原理是：在进行SSL握手时，SSL选择一种对称算法对要传输的数据进行加密，然后才在网络上传输数据。SSL使用一种很健壮的信息验证码(Message Authentication Code)，例如：SHA-1，验证码被放在数据包的后部，并且和数据一块被加密。这样，如果数据被修改，其散列值就无法和原来的验证码匹配，从而能够检测出数据是否被修改，避免了大量的恶意请求。PayPal、Facebook、Yahoo、Google的登录页面均采用了SSL协议处理。

优点：SSL的安全级别注定了采用该协议加密过的数据基本上不会有被攻破的可能;

缺点：需要服务器端SSL组件和安全证书的支持。另外由于所有传输的数据都会经过一层加密处理，一定程度上会影响用户的访问速度。

(三)通过 JavaScript 来实现客户端数据加密：

该方案的是受到 Ajax 请求方式的启发。工作原理：用户访问表单页的时候，先在后端发起一个Ajax请求，向服务器请求一个密钥，然后在用户提交表单的时候，利用这个密钥和客户端的JavaScript加密算法把用户提交的数据加密，服务器端获取到数据库，再以同样的逆算法运算，从而获取到用户提交的实际数据。由于每次服务器端产生的密钥都是不同的，所以每个密钥只对当前提交的数据有效，同时可以设置密钥的有效期，避免数据被重复提交，从一定程度上避免了恶意请求。

优点：不需要服务器端特殊组件的支持，将影响用户体验的成本降低为零;

缺点：需要考虑，如果客户端浏览器不支持JavaScript，怎么办？

没有最完美的，只有最合适的！