```html

用户验证的漏洞

去年秋天，我帮朋友排查一个后台系统。漏洞登录页看起来挺正常——用户名、用户验证密码、漏洞验证码，用户验证三件套。漏洞我随手输入 admin'-- 作为用户名，用户验证密码随便填，漏洞验证码抓包改一下。用户验证页面刷新，漏洞直接进了后台。用户验证朋友在旁边愣了几秒，漏洞说：“这系统我们用了三年。用户验证”

问题出在验证逻辑上。漏洞开发人员把用户名直接拼进了 SQL 查询字符串，用户验证没做参数化。更离谱的是，验证码的校验结果在客户端用 JavaScript 判断，服务端根本没复核。两个漏洞叠在一起，攻击者连密码都不用猜。

这种漏洞不是孤例。我翻过不少开源项目的登录模块，发现一个规律：越是看起来简单的验证流程，越容易在细节上翻车。比如“记住我”功能，很多实现是把用户名明文塞进 Cookie，有效期设成一个月。攻击者拿到这个 Cookie，改个用户名就能冒充别人。还有人把验证码的答案直接写在前端代码里，注释都没删干净。

上面这段代码是我从某个“企业级”管理后台里摘出来的。开发者的思路很直白——能跑就行。但他们忘了一件事：用户输入永远不可信。你以为是给内部员工用的，可一旦部署到公网，扫描器几分钟就能找到入口。

更隐蔽的漏洞在密码重置流程里。我见过一个系统，重置密码时要求输入注册邮箱，然后返回一个“重置链接”在页面上。没错，直接显示出来。攻击者只要知道你的邮箱，就能重置你的密码。还有一种：重置令牌用时间戳的 MD5 值，没加盐，没设过期时间。我写了个脚本，遍历过去一周的时间戳，十分钟就撞出了有效的令牌。

这些问题的根源，是开发者把“验证”当成了功能，而不是安全边界。功能可以妥协，边界不能。

多因素验证也一样。短信验证码接口没有频率限制，我试过用同一个手机号在五分钟内请求了三百次验证码，运营商没封，系统也没封。后来我用这些验证码做了个简单的暴力枚举——六位数字，一百万个组合，配合并发请求，两小时就撞开了一个账户。短信费用倒是花了不少，但比起数据泄露的代价，这点钱不值一提。

还有一种情况更让人哭笑不得。某次渗透测试，我发现登录接口在密码错误时返回“密码错误”，用户名不存在时返回“用户不存在”。这等于给攻击者送了一份用户名字典。正确做法是统一返回“用户名或密码错误”，别泄露任何额外信息。但很多开发者觉得这样用户体验不好，非要分开提示。安全与体验的平衡点，他们选错了方向。

那怎么防？参数化查询、服务端强制校验、令牌加盐且短时效、速率限制、统一错误提示——这些都是老生常谈。但真正落地时，总有人偷懒。我的建议是：把验证逻辑单独抽出来，写单元测试，模拟各种畸形输入。别等到上线了才让攻击者帮你测。

最后说个真事。某电商平台的登录接口，我提交了一个数组类型的用户名，服务端报错并返回了完整的堆栈信息，包括数据库连接字符串。我顺着这个信息，找到了他们的测试环境，里面存着十万条用户数据，密码是明文。他们后来修了，但不知道修了多久才修好。

用户验证不是一道选择题，是一道必答题。答错了，代价可能比你想的大得多。

```