做渗透测试有一段时间了，发现登录问题比较多。我想做一个更全面的总结。我会尽量写的尽可能的全面和适合新手，这篇文章可能需要一些想象力，因为问题实在是太多了，没法下海去找各种例子，还好我遇到各种登录框的时候会上网，所以大家对web登录认证比较熟悉。从子功能上分为登录框登录、忘记密码（密码重置）、修改密码、验证码、发送手机验证码、发送邮箱验证码、注册账号、登录信息错误提示、账号锁定和其他小功能组成（单点登录还需要讲原理，本文暂不涉及）。各个网站的登录都是由以上全部或部分小功能组成的（这里通过这些小功能来划分漏洞和缺陷，覆盖的比较有针对性和全面性。有点，但还是避免不了交集).从最基本最常用的栏目入手：登录框登录框账号密码服务器持久化：打开登录页面发现账号密码已经填好，点击登录直接进入后台哈哈修复解决方案：保存账号密码处理逻辑对于本地，及时销毁session。信息泄露：登录框提供示例用户名，例如示例邮箱、手机、用户名规则，导致黑客掌握规则，生成字典。修复方案：不显示示例用户名。SQL注入：用户名字段或密码字段存在Sql注入，典型的是万能密码登录（大家都知道）修复方案：使用参数绑定查询预编译语句，如果使用各种框架根据框架安全开发的要求进行XSS编程:XSS存在于用户名或密码字段，比较典型的是反映XSS攻击自己修复解决方案：使用各种XSS过滤库编码库，具体请自行百度，本文非XSS专用账号密码暴力破解：Hackers使用工具或脚本加载账号密码字典，继续尝试登录修复解决方法：添加验证码（验证码添加不正确可能导致绕过等，可能无法防范，详见下文）用户枚举：回车用户名错误提示密码不存在，输入正确的用户名提示密码错误，从而枚举用户名修复方案：使用模糊的错误提示，例如不正确的用户名或密码。账号锁定：用户爆破时，错误次数过多导致账号被锁定，然后黑客批量尝试用户名，导致大部分用户名被锁定。账号详情泄露：提交合法用户名，服务器返回与用户名相关的账号、身份、密码等详细信息修复方案：使用验证码防爆破，尽量不要使用登录次数过多来锁定，或者设置短时锁定和低频崩溃爆破：使用脚本长时间低频爆破，限制频率数比较大的防御策略修复方案：使用验证码机制和图片验证码容易识别：验证码噪声点太少或没有噪声点，使得验证码内容无法被程序识别前端生成：验证码用js制作，随机字符生成通过js填充到前端dom中。单独验证：验证码和要验证的参数不在同一个http请求中，导致验证码验证成功后被攻击，比如验证码成功抓到当前用户名和密码请求后，进行暴力破解破解留空：当验证码的值或参数为空时，可以直接进行鉴权。使用：同一个验证码可无限次使用，或验证码用完未销毁，导致爆破或任意注册。前端展示：服务器生成的验证码不是图片，但字符串直接返回给前端任意值：拦截http请求，验证码值设置任意值即可通过验证码验证低优先级：同一个http请求发送到服务器后，验证未先验证码，如先验证用户名，导致用户枚举打码平台：使用打码平台调用验证码接口获取验证码进行身份验证，返回验证码修复解决方法：验证码必须在服务器端生成，加上噪声干扰项，Twisted以图片格式返回前端即可。前端将验证码和验证参数一次请求发送给服务器。服务器首先验证验证码的存在性和正确性。验证码使用一次后，销毁手机和邮箱验证码前端展示：服务器生成的验证码返回给页面前端，导致前端看到验证信息泄露。或注册zha_egg：通过脚本不断向验证后的手机号或邮箱发送短信或邮件，导致收件人收到大量垃圾邮件。例如，同一个请求用户名和手机不匹配但仍然发送验证码，导致无法向任意号码发送短信。收费消费：单个手机号码有次数限制，短时间内使用大量不同手机号码发送数万条短信。修复方案：验证码要求有一定的复杂度，至少6位，不能返回给前端。根据客户端会话数，制定合适的锁定策略，对比账户和绑定的手机邮箱。忘记密码帐号枚举：您输入用户名提交以后系统会提示用户不存在等认证方式被篡改：输入有效用户名后，输入其他邮箱或手机即可接收验证码密码重置验证码绕过：图片验证码或手机验证码与重置账号不在同一个请求中或者使用文章中的技术绕过用户枚举：通过重置接口判断用户是否存在,并获取用户名任意账户重置：系统通过用户名和密码参数重置密码，导致任意账户密码都可以重置，从而篡改认证方式：输入合法用户名，使用黑客邮箱或手机接收系统重置的密码。修复方案：确定账户与绑定验证方式的法律关系。重要请求必须有验证码机制。对于不存在或不正确的账号使用模糊错误信息枚举任何注册用户：注册时系统提示用户名已注册，并批量枚举用户验证码绕过：使用正确的图片验证码或手机邮箱提交注册信息前先验证码，其他绕道党sql注入见上：注册字段未绑定预编译参数，导致注入手机验证码爆破：手机或邮箱的验证码太短，强度不够被蛮力破解。修复方案：在同一个请求中提交验证码和注册信息，服务器先验证验证码是否正确。验证码机制见上文组合。通过上面的各种安全绕过技术，我们可以尝试一种或多种方法来绕过验证码、手机验证等，总会有各种小漏洞组合起来进行绕过和攻击。认证机制使用的具体防御措施，比如是否使用图片验证码、手机验证码、用户枚举等。关于安全认证机制，这篇文章中有那么多认证绕过的攻击，那是什么样的呢？认证机制是否安全？上面这么多重放攻击，对抗重放攻击最有效的手段是什么？对于那些可以使用脚本或者程序自动化攻击的，最有效最好的防御手段就是验证码！！防御方法的要点是什么？如何尽可能避免各种逻辑旁路漏洞？最好减少人为的石头步骤，甚至把需要认证的参数都放在一个http请求中！对于参数过滤，可以使用正则匹配，使用正则匹配，比如邮箱，手机，***使用正则验证，可以完全避免SQL注入XSS。对于不能使用正则匹配的，使用owasp等开源的参数过滤库来防止XSS。对于同一个http请求的参数，验证码的验证优先级最高。在验证验证码时，验证它的存在和参数的存在。一次尽量不要使用接口，因为接口一般不能使用验证码给前端返回信息。采用最少信息原则，只返回必要的信息。设计安全的认证机制。登录功能：把用户名、密码等必填字段（比如验证码，验证码只有一次，足够复杂复杂）放在前端。客户一起填写，然后放到同一个http请求中提交给后台。后台判断是否有验证码参数，然后判断验证码是否正确，然后按照常规的方式判断一些字段。不能定期对参数进行过滤和转码，然后使用参数绑定和预编译查询数据库。如果有错误或不存在，会提示前端用户名或密码错误，从而防止自动化攻击和SQL注入信息泄露等。把（邮箱，手机等）放入同一个http请求，首先验证验证码的存在性、正确性和一次性使用，然后验证参数的正规格式，然后对无法验证的参数进行过滤编码，验证用户名和验证因子在以上两种情况下，即使攻击者想要进行鉴权、锁定账户、批量重置等操作，由于验证码的原因，也只会影响个位数。账号对整个系统影响不大，其他功能相同，设计时要结合实际场景，将风险降到最低！
