从一次登录接口审计看认证链路中的常见风险

背景

登录接口看起来简单，但在实际代码审计和渗透测试中，它往往是风险密度比较高的入口。认证链路通常会同时涉及账号枚举、密码校验、验证码、风控限流、会话签发、日志记录等多个环节。任何一个环节处理不当，都可能让攻击面扩大。

这篇文章整理的是我在审计 Web 系统登录模块时常用的一套检查思路，偏长期可复用，不针对某个具体产品，也不提供攻击利用流程。重点是帮助开发和安全同学识别风险点，并给出可落地的修复建议。

典型场景

常见的登录接口大致如下：前端提交用户名、密码、验证码，后端校验账号状态和密码，成功后签发 Session 或 JWT。很多系统会在这个过程中增加图形验证码、短信验证码、失败次数限制、IP 限流等机制。

问题在于，很多实现只做了“功能可用”，但没有完整考虑异常路径。例如：账号不存在和密码错误返回不同提示；验证码只在前端校验；失败次数按 IP 记录但没有按账号记录；JWT 过期时间过长；登录日志里直接记录明文密码等。这些都属于认证链路里的常见缺陷。

技术分析

审计登录接口时，我一般会先从数据流入手，梳理一次请求从入口到会话生成的完整路径：

• 请求参数：用户名、密码、验证码、设备信息、来源 IP 是否可信。
• 账号查询：是否存在账号枚举风险，查询条件是否做了规范化处理。
• 密码校验：是否使用安全哈希算法，是否存在明文或可逆加密存储。
• 验证码和限流：是否在服务端校验，是否覆盖账号维度和 IP 维度。
• 会话生成：Session ID 或 Token 是否安全随机，过期策略是否合理。
• 日志记录：是否记录敏感字段，是否存在日志注入或泄露风险。

一个比较常见的问题是返回信息过于精确。例如账号不存在返回“用户不存在”，密码错误返回“密码错误”。从用户体验看似友好，但从安全角度看，会增加账号枚举风险。更稳妥的做法是对外统一返回“账号或密码错误”，同时在服务端日志中保留更细的错误原因，便于排障。

关键检查点

1. 账号枚举

账号枚举不一定只来自返回文案，也可能来自响应时间、状态码、响应包大小。比如账号不存在时直接返回，账号存在时进入密码哈希校验，二者耗时明显不同。审计时可以关注这些差异是否明显。

建议：

• 对外错误提示保持一致。
• 响应状态码不要根据账号是否存在做区分。
• 必要时对不存在账号也执行等价耗时的伪校验，减少时间侧信道差异。

2. 密码存储与校验

密码不应明文存储，也不建议使用 MD5、SHA1 这类快速哈希直接存储。推荐使用 bcrypt、scrypt、Argon2 等适合密码存储的算法，并为每个密码使用独立盐值。

以 Spring Security 为例，使用 BCryptPasswordEncoder 是比较常见的做法：

import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;
import org.springframework.security.crypto.password.PasswordEncoder;

PasswordEncoder encoder = new BCryptPasswordEncoder(12);

// 注册或重置密码时
String hash = encoder.encode(rawPassword);

// 登录校验时
boolean matched = encoder.matches(rawPassword, hash);

注意不要自己拼接盐值后再做简单哈希，也不要把加密密钥和密码哈希存放在同一个配置里。密码哈希的目标是即使数据库泄露，也尽量增加离线破解成本。

3. 验证码与限流

验证码不是万能手段，更不能只在前端判断。验证码校验必须在服务端完成，并且与一次性标识绑定，例如 Session、临时 Token 或服务端缓存中的 challenge id。

限流也不应只依赖 IP。现实中会遇到 NAT、代理、移动网络等场景，单纯按 IP 限制容易误伤，也可能被绕开。更稳妥的是组合多个维度：

• 账号维度：某账号连续失败次数。
• IP 维度：某 IP 单位时间内失败次数。
• 设备或客户端指纹维度：辅助风控判断。
• 全局维度：异常流量高峰时的整体保护。

一个简单的限流策略可以参考：

# 示例：Nginx 层做基础 IP 限速，应用层仍需做账号维度限制
http {
    limit_req_zone $binary_remote_addr zone=login_zone:10m rate=5r/m;

    server {
        location /api/login {
            limit_req zone=login_zone burst=10 nodelay;
            proxy_pass 
        }
    }
}

这类配置只能作为第一层保护，不能替代业务层风控。业务层仍然需要记录失败次数、冷却时间和异常行为。

4. 会话与 Token

登录成功后，系统通常会签发 Session 或 JWT。这里需要关注几个点：随机性、有效期、刷新机制、退出登录后的失效策略。

如果使用 JWT，不建议把敏感信息放进 payload。JWT 默认只是编码，不是加密。常见错误是把手机号、邮箱、角色明细、甚至内部权限字段直接塞进 Token。更稳妥的做法是只放必要的 subject、过期时间和少量上下文信息，权限仍由服务端查询或缓存控制。

JWT 示例字段应保持克制：

{
  "sub": "user_id_12345",
  "iat": 1710000000,
  "exp": 1710003600,
  "iss": "example-service"
}

另外，退出登录要考虑服务端失效。如果系统完全依赖无状态 JWT，退出后 Token 在过期前仍可能可用。可以引入短有效期 Access Token 加 Refresh Token，或维护 Token 黑名单、版本号等机制。

5. 登录日志

登录日志的价值很高，但也容易引入新的泄露风险。审计时重点看日志是否包含明文密码、验证码、完整 Token、身份证号等敏感字段。

建议记录：

• 用户标识：使用 userId 或脱敏后的账号。
• 结果：成功、失败、锁定、验证码错误等内部枚举。
• 来源：IP、User-Agent、设备标识，注意可信代理链解析。
• 时间：精确时间戳，便于事件复盘。
• 请求标识：traceId 或 requestId，便于串联链路。

不建议记录：

• 明文密码、验证码、短信验证码。
• 完整 Cookie、Authorization Header。
• 未脱敏的手机号、邮箱、证件号。

代码审计时的实用方法

如果是白盒审计，可以先从路由和控制器入口定位登录相关接口，再向下追踪 Service、DAO、缓存和日志。重点关注条件分支和异常处理，因为很多认证缺陷都出现在失败路径中。

# 常见关键词检索思路，按项目语言调整
grep -R "login" ./src
grep -R "password" ./src
grep -R "captcha" ./src
grep -R "token" ./src
grep -R "BCrypt\|MD5\|SHA1" ./src

看到以下模式时需要提高警惕：

• 直接比较明文密码：rawPassword.equals(dbPassword)。
• 使用 MD5(password) 作为最终密码存储。
• 验证码校验只出现在前端代码中。
• 登录失败没有任何次数限制。
• 异常信息直接返回给客户端。
• 日志打印完整请求体。

修复建议清单

注意点

认证模块的安全加固要注意平衡可用性。比如账号锁定策略如果过于激进，可能被滥用造成拒绝服务；验证码如果频繁触发，会影响正常用户体验。比较合理的方式是分级处置：轻度异常增加冷却时间，中度异常触发验证码，高风险场景再进行临时锁定或二次验证。

另外，不要只在网关层做安全控制。网关、WAF、Nginx 限流都可以降低风险，但认证逻辑的最终可信判断仍应放在业务服务端。尤其是内部接口、移动端接口、老版本 API，往往会绕过部分前端或边缘层逻辑。

总结

登录接口审计的核心不是找某个单点问题，而是看整个认证链路是否闭环：输入是否可信、校验是否在服务端、失败路径是否可控、会话是否可失效、日志是否可追溯且不泄露敏感信息。

实际项目里，登录模块经常随着业务迭代被不断修改，历史兼容逻辑和临时开关很容易留下风险。建议把认证链路纳入常规安全基线检查，并在新增登录方式、接入第三方认证、调整验证码策略时同步做安全评审。这样比事后补漏洞更稳，也更容易维护。