Web登录认证类漏洞分析防御总结和安全验证机制设计探讨

我做渗透测试已经有一段时间了，发现有很多登录问题。我想做一个更全面的总结。我试着写一个适合新人的综合观点。这篇文章可能需要一些想象力，因为有很多问题，我不能去海边找各种各样的例子，但幸运的是我在网上冲浪时遇到了各种各样的登录框，所以每个人都更了解

网页登录认证。子功能可分为登录框登录、密码遗忘(密码重置)、密码修改、验证码、手机验证码发送、邮箱验证码发送、账户注册、登录信息错误提示、账户锁定等小功能(单点登录仍需说明原理，暂时不在本文讨论范围内)。每个网站的登录大致由上述小函数的全部或部分组成(这里的漏洞缺陷被这些小函数划分，这些小函数更有针对性，覆盖范围也更全面，但仍然不可避免地会交叉)。

从最基本和最常见的列表开始:

登录框

登录框帐户密码服务器持久性:当您打开登录页面，发现帐户密码已填写完毕，请单击登录直接进入后台，哈哈

图片验证码

手机和邮箱验证码

修复方案:保存帐户密码处理的逻辑是本地的，会话会及时破坏信息披露:登录框提供示例用户名，例如示例邮箱、移动电话和用户名规则，这会导致黑客掌握生成字典修复方案的规则:不显示示例用户名的sql注入:用户名字段或密码字段中存在sql注入。更典型的是通用密码登录(人人都知道)修复方案:使用参数绑定方法查询和预编译语句。如果XSS是根据框架安全开发的要求通过使用各种框架编程的:XSS存在于用户名或密码字段，更典型的是反射XSS打自己的修复方案:使用各种XSS过滤库编码库，详情请百度。本文不是XSS特别账户密码暴力破解:黑客通过工具或脚本加载账户密码字典，并不断尝试登录修复方案:添加验证码(不正确添加验证码可能导致旁路等。并且可能无法阻止它们，如下文详细描述的)用户枚举:不存在不正确的用户名提示密码，输入了不正确的用户名提示密码，从而枚举用户名修复方案:使用模糊的错误提示，例如，如果用户名或密码不正确，则帐户被锁定:当用户爆炸时，用户锁定帐户，错误太多，然后黑客批量尝试用户名， 导致大部分锁定帐户的详细信息被披露:提交合法用户名，服务器返回有关帐户、身份、密码等的详细信息。 与用户名相关的修复方案:使用验证码防止爆炸，并尽量不要使用登录次数过多的锁定方法。或者设置短期锁定低频库爆破:使用脚本以较低频率进行长期爆破，针对有限频率相对较多的防御策略修复方案:使用验证码机制查蛋(Zha_ Egg):通过脚本向被验证的手机号码或邮箱发送短信或电子邮件，导致接收者接受大量垃圾信息账户锁定:单个手机或邮箱被锁定一定时间超过一定次数，自动批量锁定账户不匹配:例如，它与请求的用户名和手机不匹配，但仍然发送验证码， 导致向任何号码发送短信的费用:一个手机号码的使用次数是有限制的。 使用大量不同的手机号码在短时间内发送数万条短信修复方案:验证码必须具有一定的复杂度，至少6位数，并且不能返回前端。基于基于客户端会话的次数限制，制定了适当的锁定策略。账号与绑定手机邮箱是否匹配

忘记密码

账号枚举:输入用户名并提交后，系统提示用户篡改不存在等认证方式；输入合法用户名后，其他邮箱或手机可以接收验证码

密码重置

验证码旁路:图片验证码或手机验证码与重置账号不在同一请求中，或者使用文章中的技术绕过用户枚举:通过重置界面判断用户是否存在。获取用户名的任意账户重置:系统通过用户名和密码的参数重置密码，使任意账户的密码在认证模式下被重置和篡改:输入合法用户名，使用黑客邮箱或手机接收系统重置的密码恢复方案；判断账户与绑定认证模式之间的法律关系，并在重要请求中包含认证码机制。对于不存在或不正确的账户，模糊错误报告提示信息

任意注册

用于用户枚举:注册时，系统提示用户名已经注册，用户验证码的批量枚举绕过:使用正确的图像验证码或手机邮箱验证码后，提交注册信息。有关其他绕过方法，请参见上面的sql injection:注册字段没有与预编译参数绑定，导致注入的手机验证码爆发:手机或邮箱的验证码太短。弱爆修复方案:在同一请求中提交验证码和注册信息，服务器将优先验证验证码是否正确。有关验证码机制，请参见上面的@

组合绕过

通过上述各种安全旁路技术，我们可以尝试一种或多种方法来绕过验证码、手机认证等。总会有各种各样的小漏洞被组合起来绕过和攻击。具体来说，查看认证机制使用了哪些防御措施，例如图片验证码、移动电话验证码、用户枚举等。

安全的认证机制

如上所述，绕过了这么多身份验证攻击，哪种身份验证机制是安全的？上面有这么多重放攻击，对抗重放攻击最有效的方法是什么？

对于可以被脚本或程序自动攻击的攻击，最有效的防御方法是验证码！

防御手段有哪些关键点呢?

如何尽可能避免各种逻辑绕过的漏洞？最好减少人造石的步骤，甚至将所有需要认证的参数都放入http请求中！

一个安全的认证机制的设计

在上述两种情况下，即使攻击者想闯入数据库，锁定账号，批量重置账号等。验证码只会影响一位数的账号，对整个系统影响不大。

对于其他功能，如果将设计与实际场景相结合，风险可以降至最低。