app登录口令绕过漏洞

去年秋天，登洞某电商App的录口令绕登录接口被曝出一个低级漏洞：把请求里的"user_id":123改成"user_id":1，就能直接以管理员身份进入后台。过漏没有验证码，登洞没有二次校验，录口令绕连token都没换。过漏这个漏洞后来被厂商用“业务逻辑缺陷”四个字轻描淡写地盖过去了，登洞但懂行的录口令绕人都知道，这就是过漏典型的登录口令绕过。

登录绕过不是登洞什么高深的技术。它不依赖0day，录口令绕不需要逆向加密算法，过漏很多时候就是登洞开发人员少写了一个if判断。比如有的录口令绕App在客户端做校验——你输入密码，前端JS比对一下，过漏对了就发个isLogin=true的字段给服务器。攻击者抓包改包，服务器一看isLogin=true，门就开了。这种设计等于把钥匙插在门上，还贴了张纸条写着“欢迎光临”。

我见过更离谱的。某金融类App的“忘记密码”流程里，验证短信验证码的接口和重置密码的接口是分开的。你用自己的手机号收验证码，通过校验后，服务器返回一个reset_token。然后重置密码的请求里带上这个token和user_id。问题出在user_id没有和token绑定。攻击者用自己的手机号走完验证流程，拿到合法token，再把user_id改成受害者的，密码就重置了。整个过程中，短信验证码是真的，token也是真的，唯独身份是假的。

这类漏洞的根源往往不在技术层面，而在开发流程里。很多团队把登录模块当成“一次性代码”——写完能跑通就行，后面加功能时直接在上面叠逻辑。今天加个第三方登录，明天加个免密支付，后天加个员工内部通道。每加一层，就多一个绕过点。我见过一个App的登录逻辑里，光是判断“是否已登录”的字段就有四个：isLogin、logged_in、auth_status、session_valid。四个字段各自为政，改其中一个就能骗过某条分支。这种代码维护起来像拆炸弹，剪错一根线就炸。

测试环节也经常放水。功能测试只测“正确密码能登录”，不测“错误密码加篡改参数能不能登录”。安全测试又往往只跑自动化扫描工具，而工具对逻辑漏洞的识别率极低。一个手动测试工程师花十分钟就能发现的绕过，扫描器跑一万遍也报不出来。结果就是漏洞上线，等被人扒出来才连夜发补丁。

要堵住这类漏洞，思路其实很朴素：所有身份校验必须在服务端完成，且每次请求都要重新验证。客户端传来的任何“我已登录”标记都不可信。user_id这类身份标识必须从服务端会话里取，不能从请求参数里读。验证码、token、会话ID三者要绑定，换一个就全废。听起来都是常识，但常识在赶工期的时候最容易被牺牲。

有个做安全的朋友跟我说过一句话：登录绕过漏洞像蟑螂。你发现一个，说明墙缝里还藏着一窝。这话不夸张。一个接口能绕过，往往意味着同一套鉴权逻辑复用在十几个地方。修一个不够，得把整条链路翻出来重写。所以下次看到“业务逻辑缺陷”这种修复说明，别急着信。问问他们：改了几个接口？加了几层校验？回归测试跑了吗？

登录是App的门。门都关不严，里面装修得再漂亮也没用。

很赞哦!（71）