用户名枚举漏洞

用户登录框弹出时，用户没人会想到“用户名”三个字本身就是名枚漏洞。但攻击者知道。举漏他们不急着猜密码，用户先拿用户名试水——输入“admin”，名枚服务器回“密码错误”；输入“zhangsan”，举漏回“用户不存在”。用户两行字的名枚差异，等于把内部账号名单白送了出来。举漏这叫用户名枚举，用户比暴力破解更安静，名枚也更致命。举漏 我见过一个真实案例。用户某银行内部系统，名枚攻击者写了个脚本，举漏每秒发20次登录请求，把字典里两万个常见姓名全跑了一遍。服务器很诚实：不存在的用户返回“账号未注册”，存在的返回“密码错误”。一晚上过去，攻击者手里攥着431个有效员工账号，连密码都没碰。后续钓鱼邮件精准投递，成功率翻了三倍——因为邮件开头能直呼其名。 技术原理不复杂。HTTP响应体、状态码、跳转逻辑，甚至响应时间都可能泄露信息。有的系统登录失败返回200，但JSON里藏着`"user_exists": true`；有的返回302重定向到不同页面；更隐蔽的，账号存在时服务器多算了两次数据库查询，响应慢了80毫秒。这些细节，全是攻击者的“温度计”。 别觉得换套复杂密码就安全。密码是第二道门，用户名是第一道锁。锁的齿形都被人拓印走了，门再厚也白搭。真正的风险在于：多数系统把“用户名不存在”和“密码错误”分开提示，本意是方便用户记忆，结果成了信息泄露的通道。更蠢的是有些开发者在注释里写“// TODO: 统一错误提示”，然后忘了改。 防御手段其实不复杂，但需要点反人性思维。第一，统一错误文案，管你用户存不存在，全回“用户名或密码错误”。第二，做逻辑层限速——同一IP五分钟内错三次就锁十五分钟，别只靠前端按钮置灰。第三，关键系统直接上验证码，滑块那种都行，成本低但能卡死脚本。第四，记录异常模式：同一IP批量试不同用户名、同一用户名高频试密码，都该触发告警。 有个细节很多人忽略：注册页面同样会泄露。输入新用户名，系统提示“该用户名已被注册”——这等于反向枚举。处理办法是延迟响应，或者强制要求邮箱验证后再提示冲突。还有密码找回功能，“该邮箱未绑定账号”也是典型泄露点。攻击者不傻，哪里能给反馈，哪里就是突破口。 说到底，用户名枚举算不上高深攻击，但它是所有后续攻击的垫脚石。就像小偷踩点先看你家窗户有没有关严，而不是直接撬锁。系统设计者该明白：每个响应细节都在说话。要么让所有回答都变成“无可奉告”，要么就等着被摸清底细。这个选择，不该留给攻击者来做。