用户枚举漏洞危害

登录框里输入一个手机号，用户系统回你“该用户不存在”。枚举换一个号码，漏洞返回“密码错误”。危害两个不同的用户提示，等于把用户数据库的枚举大门钥匙递了出去。这不是漏洞猜测，这是危害确认。

去年某电商平台被拖库，用户攻击者后来在论坛上晒出了自己的枚举渗透笔记。第一步不是漏洞注入，不是危害爆破，就是用户坐在登录页面手动输入了二十个手机号。系统对未注册号码返回“账号未注册”，枚举对已注册但密码错误的漏洞返回“密码错误”。二十分钟，他整理出了一份该平台真实用户的手机号列表。后面的事就顺理成章了——定向钓鱼短信发出去，转化率高得吓人。因为短信里能准确叫出对方名字，甚至提到最近一笔订单的商品。

用户枚举漏洞的本质，是系统在交互过程中泄露了“这个账号是否存在”的信息。渠道远不止登录框一个。注册页面输入邮箱，提示“该邮箱已被注册”；找回密码时输入手机号，提示“该手机号未绑定账户”；甚至API接口返回的JSON里，错误码都能区分“用户不存在”和“密码错误”。这些细节单独看都合理，合在一起就是一套完整的账号探测工具。

危害的链条比多数人想的要长。拿到有效账号列表只是起点。攻击者可以针对这批确认存在的账号做密码喷洒——用“123456”“password”“生日+姓名”这类弱口令去试。因为账号是真实的，不会触发“用户不存在”的无效请求，很多风控系统根本不会拦截。某次内部红队演练，我们靠一个枚举漏洞加密码喷洒，三个小时拿到了十七个员工邮箱的访问权限。其中一个是财务总监的。

更隐蔽的玩法是结合社会工程。知道某个手机号注册了某金融App，就能伪造“账户异常”的短信，引导用户点击钓鱼链接。用户看到短信里准确提到了自己注册过的平台名称，警惕性直接减半。这种精准打击，比广撒网式的诈骗短信效率高出几个数量级。

有些开发者的反应是：“那就统一返回‘用户名或密码错误’不就行了？”对，这是最基本的修复。但问题往往出在别的地方。比如注册接口的响应时间——已存在的用户名，数据库查询后直接返回；不存在的用户名，要走完整个插入流程才报错。时间差超过200毫秒，就能被脚本稳定识别。还有短信验证码接口，对已注册手机号发送验证码，对未注册的返回“该号码未注册”，这等于把枚举漏洞从登录口搬到了短信口。

我见过最离谱的一个案例，某政务系统的API在用户不存在时返回HTTP 404，存在但密码错误时返回401。状态码不同，枚举脚本连响应体都不用解析。修复方案其实不复杂：统一错误提示、统一响应时间、限制单位时间的尝试次数、对高频枚举行为加验证码或直接封IP。但很多团队在业务压力下，总把这些当成“以后再说”的事。

攻击者不需要多高的技术。一个Python脚本，一个代理池，加上从网上扒来的手机号段字典，就能在半夜把目标系统的用户量摸个七七八八。第二天早上安全团队看到告警，数据早就落到别人手里了。用户枚举漏洞像一扇没关严的窗户，风一吹就开。你永远不知道站在窗外的人，只是好奇往里看了一眼，还是已经准备好了梯子。