Web登录认证类漏洞分析防御总结和安全验证机制设计探讨
来源：岁月联盟
时间：2020-01-29
手机验证码爆破：手机或者邮箱的验证码太短，不强壮被暴力破解
修复方案：把验证码和注册信息在同一请求提交，服务端优先验证验证码是否正确，验证码机制见上文
组合绕过
通过上文各种安全绕过技术，我们可以尝试一种或多种手段绕过验证码、手机验证等等，总会有各种各样的小漏洞被组合绕过进而进行攻击，具体的看认证机制使用了哪些防御措施，比如是否使用图片验证码、手机验证码、用户枚举、等等吧
安全的认证机制
上文中，关于认证的攻击绕过那么多，那么样的认证机制是安全的？上面重放攻击那么多，什么是对抗重放攻击最有效的手段？
对于可以使用脚本或者程序自动化攻击的，最有效的防御手段就是验证码！！
防御手段有哪些关键点呢？
如何尽可能的避免各种逻辑绕过的漏洞？最好减少人造石步骤，甚至把需要认证的参数全放一个http请求中！
对于参数过滤，可以使用正则匹配就使用正则，比如邮箱、手机、***使用正则验证，完全可以避免sql注入XSS这些
对于不能使用正则匹配的，对参数使用owasp等组织开源的过滤库防止XSS
对于同一个http请求的参数，验证码拥有最高优先级验证，验证码验证时要验证其存在性、参数的存在性、一次性
尽量不要使用接口，因为接口一般不能使用验证码
往前端返回信息，使用最小信息原则，只返回必要的信息
一个安全的认证机制的设计
登录功能：把用户名密码和其他需要的字段（如验证码，验证码只有一次，并足够杂点和复杂度）放前端让客户一起填写，然后放到同一个http请求提交给后端，后端判断是否有验证码参数，然后判断验证码是否正确，再然后正则判断部分字段，不能正则的对参数进行过滤转码，然后使用参数绑定和预编译查询数据库，出错或者不存在的提示前端用户名或者密码错误，这样就防止了自动化攻击和SQL注入信息泄露等等
密码重置功能：把验证码、用户名、认证因子（邮箱、手机等）放到同一个http请求中，优先验证验证码的存在性、正确性、一次性，其次对参数进行正则格式验证、之后对不能验证参数进行过滤编码、验证用户名和认证因子的匹配性、最后再触发相关功能
上面两种情况，即使攻击者想撞库、锁定账号、批量重置等操作，也会因为验证码而只能影响个位数的账号，对系统整体影响不大。
其他功能同理，要结合实际的场景进行设计，即可把风险控制到最小！
上一页 [1] [2]
