用户枚举漏洞

登录框里输入一个手机号，用户系统提示"该用户不存在"。枚举换一个号码，漏洞提示"密码错误"。用户这两个不同的枚举反馈，就是漏洞用户枚举漏洞的入口。

说白了，用户用户枚举就是枚举攻击者能通过系统的响应差异，判断出某个账号到底存不存在。漏洞听起来好像没什么大不了？用户但它的危害比很多人想象的要大得多。你知道了哪些手机号注册过这个平台，枚举接下来就可以针对这批真实用户做精准的漏洞钓鱼、撞库、用户短信轰炸。枚举攻击面一下子从"盲打"变成了"点名"。漏洞

我去年帮一个朋友看他们公司刚上线的App，注册接口做得挺漂亮，前端校验也齐全。但抓包一看登录接口的返回体，账号不存在时返回 { "code": 1001, "msg": "用户不存在"}，密码错误时返回 { "code": 1002, "msg": "密码错误"}。两个不同的状态码，明晃晃地告诉攻击者：恭喜你，这个手机号是真实用户。

漏洞藏在哪里

最常见的位置就是登录、注册、找回密码这三个功能点。登录接口的差异最直白——错误提示不同、响应时间不同、甚至HTTP状态码不同，都能泄露信息。注册接口也很有意思，你输入一个手机号，它告诉你"该手机号已注册"，这等于免费送了一个账号查询接口。找回密码同理，"该邮箱未注册"和"验证码已发送"就是两种截然不同的信号。

响应时间这个维度容易被忽略。有些系统为了避免文字提示泄露信息，统一返回"用户名或密码错误"。但后端逻辑是先查用户再验密码——用户不存在时直接返回，用户存在时才走密码比对流程。后者多了一步bcrypt哈希计算，可能多花几十甚至上百毫秒。攻击者跑几千次请求取平均值，照样能把存在的账号筛出来。这种时序侧信道，比文字提示更隐蔽，但一样致命。

一个真实的撞库链条

2023年有个案例让我印象很深。某电商平台的登录接口做了统一的错误提示，看起来没问题。但它的短信验证码接口没有做频率限制，而且对已注册和未注册手机号的返回内容有细微差别——已注册的号码返回的验证码短信模板里多了一个"尊敬的用户"前缀。攻击者写了个脚本，用一批手机号段跑了一遍，筛出几万个真实用户，然后拿这批号码去其他平台撞库。因为很多人多个平台用同一个密码，最终导致大量账号被盗。

这个链条的起点，就是用户枚举。

怎么防

核心原则就一条：让攻击者分不清"用户不存在"和"密码错误"。登录接口统一返回"用户名或密码错误"，HTTP状态码保持一致，响应时间也要尽量拉齐——用户不存在时也走一遍假的密码哈希比对，把时间差抹平。注册和找回密码环节，不要直接告诉用户"该手机号已注册"，改成"如果该手机号已注册，你将收到一条短信"。把判断逻辑放到后端异步处理，前端只给统一的模糊反馈。

另外，加频率限制和行为验证。同一IP或同一设备短时间内大量尝试不同账号，直接触发验证码或临时封禁。这不光防枚举，也防撞库。

用户枚举本身可能不算高危漏洞，但它是很多攻击链的第一步。单独看它，好像只是泄露了一个"是否存在"的布尔值。但把这个布尔值乘以几万次请求，得到的就是一份精准的用户名单。这份名单在黑产手里的价值，远比很多人以为的要高。

很赞哦!（129）