深入探讨Web登录认证漏洞

0x0 前言

在我的渗透测试经验中，经常发现目标站点在登录方面存在诸多问题。对于Web登录认证，我一直期待撰写一篇全面的总结，但由于目前仍处于实习阶段，工作较为繁忙，所以一直未能实现。现在终于得以展开讨论。废话不多说，下面将对Web登录认证漏洞的安全验证设计机制进行深入探讨。

一、用户登录

当我们打开浏览器访问网页时，通常会遇到一些需要用户认证的后台界面。这些界面不是所有用户都能访问的，就像我们回家需要进入家门一样，这时家门就是一道认证，手中的钥匙就是进入的凭证。然而，这种认证并不总是安全的。接下来将探讨一些存在的漏洞。

1. 用户枚举

这是Web用户登录中最常见的漏洞之一。在用户登录时，当输入错误的用户名时提示账号不存在，输入正确的用户名时提示密码错误，这种情况导致了对用户名的枚举。

利用思路： 使用工具进行暴力破解，如BurpSuite、Hydra。当枚举出用户账号后，然后针对指定用户进行密码爆破。如果存在账号锁定策略，可以编写脚本制造大量的恶意登录，导致大部分用户（如管理员）无法正常登录后台业务。

修复方案：

1. 使用模糊的错误提示，如用户名或密码不正确。
2. 采用有效的验证码机制（添加验证码也不一定能完全防止，下文详细说明）。

2. 账号锁定

说明：后端登录机制采取用户登录错误次数过多锁定账号。

利用思路： 编写脚本批量登录或使用bp（Burp Proxy）爆破用户账号，导致大部分用户被锁，使业务系统无法正常运转。

修复方案：

1. 使用有效验证码方式防爆破。
2. 尽量避免使用登录次数太多锁定的方式，或者设置短时锁定。

3. 账号密码暴力破解

暴力破解是通过逐个尝试密码字典中的密码，直到找到正确的用户名和密码组合。这种方法取决于字典是否包含密码。

利用思路： 使用工具如Burp Proxy进行密码爆破。

绕过思路1： 反编译apk，找到校验证书方法，将校验部分删除，变成情况1，成功抓取数据包。

绕过思路2： 使用Xposed模块JustTrustMe.apk绕过SSL证书检查。

绕过思路3： 使用Frida进行绕过，通过修改Frida脚本实现绕过证书检查。

修复方案：

1. 使用合适的证书验证机制。
2. 对于移动端，考虑使用证书脱壳等技术来保护证书。

情况3 – 双向认证

对于双向认证，APK客户端对服务器证书进行认证，服务器对客户端证书进行认证。客户端私钥通常存储在APK本身内，攻击者可尝试寻找私钥并使用它进行证书签名。

攻击思路： 寻找私钥并利用它对证书进行签名，绕过服务器校验。

修复方案： 使用合适的证书验证机制，并保护客户端私钥。

二、用户注册

注册功能在网站中很常见，但同样存在多个安全问题。

1. 用户枚举

注册时系统提示用户名已注册或用户未注册，导致攻击者可以通过爆破方式批量枚举用户。

利用思路：

1. 枚举用户名，然后针对该用户进行密码爆破。
2. 利用脚本不断向验证手机号或邮箱发送短信或邮件，导致接收方接受大量垃圾信息。
3. 写脚本批量锁定账号。

修复方案：

1. 设置短信发送时间间隔和发送次数限制。
2. 使用图形验证码进行验证。

2. 任意用户注册

注册功能的图形验证码失效，手机验证码无失效时间且为4位数，可以通过爆破手机验证码使用任意手机号码进行注册。

利用思路：

1. 通过爆破手机验证码使用任意手机号码进行注册。
2. 枚举已有用户。

修复方案：

1. 设置有效和复杂的验证码。
2. 将短信验证码位数设定为6，增加爆破难度。
3. 设定错误注册限制，当用户短信验证码输错次数超过一定次数时，该验证码失效。

3. SQL注入

用户名字段或密码字段存在SQL注入漏洞，尤其是二次注入。

攻击思路： 利用二次注入漏洞进行攻击，例如注册时修改admin密码。

修复方案：

1. 使用参数化查询，检查变量数据类型和格式。
2. 使用SQL语句预编译和绑定变量。

三、验证码

验证码是Web认证中常见的安全机制，包括图片验证码、短信验证码和邮箱验证码。

1. 图片验证码

问题1： 验证码复用，在特定条件下不失效。

问题2： 验证码易识别，杂点太少或无杂点，导致可以用程序识别出验证码内容。

修复方案：

1. 验证码在服务端生成，添加杂点和干扰项，足够扭曲，并以图片格式返回前端。
2. 服务端应优先验证验证码的存在性、正确性和一次性特性，然后对其他参数进行正则格式验证。
3. 数据提交时，验证码和登录/注册信息在同一HTTP请求中提交，服务端应首先验证验证码是否正确，最后触发相关功能。

2. 登录数据传输

修复方案：

1. 采用HTTPS加密通道进行数据传输。
2. 使用有效的加密算法对敏感数据传输进行加密。

3. 手机和邮箱验证码

修复方案：

1. 验证码应具有一定复杂度，至少6位，且不能返回前端。
2. 基于客户端session进行次数限制，并制定合适的锁定策略。
3. 在进行敏感数据操作时，对比账号和绑定的手机/邮箱是否匹配，进行多次验证。

安全的认证机制建设

通用修复方案：

1. 永远不要相信用户在数据交互点的输入数据，做好相应的参数过滤。
2. 针对SQL注入，使用参数绑定或预编译查询。
3. 对于XSS，使用正则判断部分字段，对用户输入的恶意代码进行过滤。

以上是一个安全的认证机制建设的基本规则，确保在用户提交敏感数据时，验证码和登录/注册信息在同一HTTP请求中提交，服务端应优先验证验证码的存在性、正确性和一次性特性，最后触发相关功能。