用户名枚举漏洞，用户说白了就是名枚网站自己把“这个账号存不存在”给泄露了。攻击者根本不用猜密码，举漏光靠注册、洞百度百登录、用户找回密码这几个入口，名枚就能把平台上的举漏真实用户名摸个一清二楚。

最典型的洞百度百场景是登录框。你输个不存在的用户账号，比如“zhangsan1988”，名枚系统秒回“该用户不存在”；换一个真实存在的举漏，比如“admin”，洞百度百它就变成“密码错误”。用户就这一字之差，名枚等于网站亲手把用户名单递到了黑客手里。举漏更气人的是，有些平台连错误提示都懒得统一，一个说“用户名或密码错误”，另一个说“用户名不存在”，生怕别人看不出来区别。

找回密码功能更是重灾区。你填个邮箱或手机号，系统告诉你“重置链接已发送”——但前提是账号存在。不存在的账号呢？直接弹“该账号未注册”。这哪是找回密码，分明是给攻击者开了一扇免费的情报窗口。2019年某知名社交平台就栽在这上面，攻击者用脚本批量遍历手机号，几天功夫捞走了上百万个注册用户的有效号码，后来被拿去搞精准诈骗，闹得沸沸扬扬。

注册页面同样不省心。你输个新用户名，它提示“已被注册”，换个生僻组合又提示“可用”。这等于在公开招标：哪些名字被占了，哪些名字还空着。对搞撞库的人来说，这就是一份现成的字典——先枚举出真实账号，再拿这些账号去试常用密码，效率直接翻倍。

别以为这只是小毛病。用户名一旦确认，后面跟着的就是社工攻击、钓鱼邮件、甚至账号锁定攻击。攻击者可以故意输错密码把某个账号锁死，让真正用户登不进去，再冒充客服联系用户套取信息。一环扣一环，源头就是那个不起眼的“该用户不存在”。

修复办法倒不复杂，核心就一条：把所有错误提示统一成模糊说法。不管账号存不存在，登录都回“用户名或密码错误”，找回密码都回“如果该账号存在，重置链接已发送”。后端响应时间也得做点手脚——查无此人和密码错误如果耗时差太多，照样能被人用计时攻击测出来。再狠一点，加上图形验证码或短信验证限制频率，把批量遍历的路堵死。

但现实是，很多中小网站根本没当回事。开发图省事，直接拿数据库返回的错误码当提示文案，测试时也没人较真去试账号不存在的情况。等到被刷爆了才着急补洞，数据早就漏光了。这玩意儿不痛不痒，可一旦被盯上，就是连锁反应的起点。

说到底，用户名枚举拼的不是什么高深技术，而是细节。一个提示文案、一个响应时间差，都可能变成突破口。做产品的要是连这点敏感度都没有，那离出事也就不远了。