安全方案-验证码

一、验证码的作用

网络平台防止恶意注册(代码代替人去完成注册)提出的解决方案。攻击者可以自行构造客户端，短时间内发送多个注册成功的请求。

二、仅靠前端实现的验证码是否安全?

如果验证码仅仅由前端实现，这种场景下攻击者依然能绕过正规的客户端（浏览器），自行构造客户端去进行恶意注册。只是在构造请求时，多加一个验证码校验成功的参数而已。依然解决不了恶意注册的问题。

三、正确解决方案

用户输入完验证码之后，将输入传递给服务端，服务端去校验验证码是否正确（校验从单独的前端校验，转移到了后端的校验）这样就算攻击者绕过了客户端，那么服务端的校验也很难通过。

四、原理

服务端生成验证码，客户端(前端)提交输入，由服务端将输入和回传过来的验证码 id (或将唯一 key植入 cookie)进行对比。通过，则进行正常的登录逻辑

五、验证码类型

• 随机数字
• 数字计算
• 图片选择(例：12306注册)
• 点击式图片验证(依次点击“一二三四”)
• 短信验证码
• 拼图验证

六、验证码时效性

对于验证码，需要保证每一次的验证码都与上一次的不同。校验规则以最近一次为准。对于手机验证码的五分钟有效这个设定，是在时限上做了限制，如果五分钟内枚举不出正确的验证码，那么就得从新来过。但是对于机器代码枚举速度效率极快，这种时限性的限制，作用微乎其微，更多的是在短信成本上做了优化。

七、实现方案

• 随机数字或数字计算
  后台请求图片，以及跟验证码对应的唯一标识。不需要结果（正确结果或跟图片对应的正确的数字），等待用户输入之后，将输入与 ID 回传给后端，由后端比对正确结果，进行校验。如果出错，则立马更新一张验证码(为了防止脚本无限试错)。
• 点击图片式认证
  后台存储图片文字坐标，将验证码发送给前端。前端拾取用户点击的坐标。此坐标需要换算。因为后台存储的坐标可能是根据图片左上角的位置进行的定位。前端拾取的点击事件收集到的坐标，是根据浏览器左上角的坐标系来进行的换算（向右(x)向下(y)为正方向）。如果发生错误，马上更换一张新的验证码
• 短信验证码
  后台需接入第三方短信平台。前端回传。验证码未失效时，可一直更换输入验证码结果。后台根据手机号去匹配验证码是否正确
• 滑动拼图
  JS 实现滑块验证码
  S 实现滑块验证码2
  getBoundingClientRect
  cavas 相关 API