登录绕过漏洞，登录说白了就是绕过攻击者不输入正确密码，也能堂而皇之地进入系统。漏洞它比暴力破解更可怕——暴力破解好歹要猜，登录绕过是绕过直接跳过了门禁。

我见过最典型的漏洞案例，是登录一家SaaS公司。他们的绕过重置密码接口用了一个“安全”设计：用户请求重置密码后，服务器会返回一个token到邮箱，漏洞然后把token拼在URL里。登录听起来没问题对吧？绕过但开发图省事，把token的漏洞校验逻辑写在了前端JavaScript里。攻击者打开浏览器开发者工具，登录把token改成任意值，绕过然后删掉校验函数——直接跳过了验证步骤，漏洞进入了密码重置页面。更讽刺的是，这个漏洞上线了两年，直到一次渗透测试才被发现。

这类漏洞的核心成因，往往是开发者默认“用户不会看代码”。他们忘了，攻击者会。另一个常见姿势是“越权”——水平越权：登录后修改URL里的用户ID，就能看到别人的订单；垂直越权：普通账号调用管理员接口，权限校验只在前端菜单隐藏，后端根本不管。有一次我测试某后台管理系统，退出登录后按浏览器后退键，居然还能看到上一个用户的页面。因为系统只在前端做了登录状态判断，服务端压根没校验session是否有效。

还有一类更隐蔽的——逻辑顺序绕过。比如某银行App的转账流程：先验证短信验证码，再输入支付密码，最后确认。攻击者发现，如果第一步验证通过后，快速抓包修改第二步的请求参数，把“校验支付密码”这个字段改成“false”，服务端就真的跳过了密码校验。这种漏洞不是技术高深，而是业务逻辑设计有漏洞——服务端没有强制每一步的状态流转。

说白了，登录绕过之所以频繁发生，是因为很多团队把“登录”看作一个功能，而不是一条安全链路。功能只关心能不能用，链路关心每一步是否可信。我见过不少开发者在登录接口里写“if (user != null) { login success }”，他们以为只要查到了用户就代表密码正确——鬼知道那个“user”是从哪里来的。

要防住这类攻击，最笨也最有效的方法是：所有关键操作，服务端必须重新校验身份和权限。前端的一切都不可信——token可以伪造，请求可以篡改，页面可以调试。别信“用户不会看代码”这种鬼话，真正的攻击者比开发更懂代码。还有，每次登录、重置密码、权限变更后，服务端要生成新的session，旧的立刻作废。别嫌麻烦，安全本来就是麻烦事。

最后说一句，如果你发现自己写的代码里有“前端判断登录状态”“后端不校验权限”“token写死在JS里”这种操作——别等黑客来，自己先改了吧。