一键登录的致命缺陷：拦截返回包改个phoneNumber，我就登录了你的账号 ...

2026-6-19 18:47 21 0

摘要: userId 、 phoneNumber 、 openId 这些字段，只能从服务端的Session或Token中读取。APP调用运营商SDK，运营商在基站侧识别你的手机号，生成一个加密token返回给APP。很多开发者的逻辑是：运营商的token已经保证了手机号的真实性，所以后端解密出来的手机号一定是对的。

关键词：Token, userId, phoneNumber, Burp, OpenID, APP, Session, Gin, 手机号, 运营商

上次测一个社交APP，登录页挺干净，就一个“本机号码一键登录”按钮。没输入框，没密码，没验证码，点一下就登进去了，体验丝般顺滑。

但我总觉得不对劲。Burp开起来，抓了登录的响应包，看到这么一段JSON：

{ "code": 200,"data": { "phoneNumber": "138****1234","token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." }}

我把 phoneNumber 后面的 138****1234 改成了 139****5678 ，放行。APP直接跳进了主页，顶上写着：“欢迎，139****5678”。

不是我的账号，我登录了别人的号。整套操作花了一分钟。后来我在这个APP里翻到了另一个高危接口，可以导出全量用户数据。两个洞打包提交，一个严重。

一、一键登录的流程，问题出在最后一步

一键登录是运营商提供的“网关认证”能力。APP调用运营商SDK，运营商在基站侧识别你的手机号，生成一个加密token返回给APP。APP把token发给自己的后端，后端用运营商的公钥解密token，拿到手机号，然后返回给前端——所谓“返回”，就是把这个手机号拼在JSON里告诉前端“你是谁”。

问题就出在这个“返回”上。

很多开发者的逻辑是：运营商的token已经保证了手机号的真实性，所以后端解密出来的手机号一定是对的。于是直接把解密出来的手机号写进响应体，前端拿这个手机号去执行登录逻辑。

但攻击者根本不需要关心token怎么解密。他只需要在响应体离开服务器后、到达APP前，把里面的 phoneNumber 字段改成别人的号码。如果APP的登录逻辑是“收到哪个手机号就登录哪个账号”，那攻击者改什么号，就登什么号。

更深一层的问题在登录接口本身。我测过很多APP，一键登录的接口长这样： POST /api/login/byPhone ，请求体里只有一个 phoneNumber 字段。后端收到后，直接根据 phoneNumber 查询用户表，生成token返回。它根本不管这个 phoneNumber 是不是从运营商token解密出来的，还是攻击者自己填进去的。

这意味着什么？即使你不走一键登录的流程，直接调用登录接口，传一个手机号进去，也能登录。所谓“一键登录”的安全性，完全建立在“前端不会骗我”的假设上。而Burp Suite的存在，让这个假设成了笑话。

二、一个真实案例：从改包到全站数据泄露

今年年初测的一个在线教育平台，使用一键登录。登录接口的完整流程是这样的：

第一步，APP调用运营商SDK，拿到token。第二步，APP把token发给后端 /api/login/token 。第三步，后端解密token，返回

{"phoneNumber":"138xxxx1234","userId":"10086","nickName":"张同学"}

。第四步，APP调用

/api/login/byPhone?phone=138xxxx1234

完成登录。

我在第三步截住了响应包，把 phoneNumber 和 userId 都改了—— phoneNumber 改成 139xxxx5678 ， userId 从数据库里猜了一个 10087 。放行后，APP拿篡改过的参数去调第四步的登录接口，后端直接返回了 139xxxx5678 账号的完整token。

拿到token后，我在APP里浏览个人信息，看到了另一个学生的真实姓名、身份证号、家庭住址。接着我测了一个越权洞——修改 /api/user/profile?userId=10088 的参数，遍历userId，拿到了全站所有用户的个人资料。这个洞最终被定为严重，理由是一条攻击链：一键登录响应包篡改 + 越权 = 全量用户数据泄露。

三、手工操作三步走

第一步，抓登录响应包。Burp配置好代理，手机连上Burp的WiFi代理，安装Burp证书。打开目标APP，点击“一键登录”。Burp的Proxy标签页会出现登录接口的响应包。

第二步，找到并修改phoneNumber。在响应包里搜索 phone 、 mobile 、 phoneNumber 、 mobileNumber 、 cell 等字段。找到后直接改后面的值。注意有些APP返回的是脱敏手机号（ 138****1234 ），这种改不了——但大部分APP返回的是明文，因为它要做后续的账号绑定逻辑。

第三步，放行观察。点Forward后，看APP是否跳转到主页、是否显示被篡改后的用户信息。如果能正常进入，说明漏洞存在。

进阶技巧：有些APP在响应包里返回了 userId 或 userToken ，直接修改这些字段可能连token都不用走，直接切换账号。更激进的做法是用Burp的Match and Replace功能，把所有响应体里的 phoneNumber 自动替换成目标号码，每次登录都自动切换。

四、不止一键登录——这个问题的本质是什么

一键登录的响应包篡改只是冰山一角。它的本质是： 后端信任了前端传递的身份标识 。

这种信任错位在很多场景都存在。微信OAuth回调返回 openId ，如果后端直接把这个 openId 返回给前端用来登录，前端改了 openId 就能登录别人账号。修改密码接口返回 {"success":true} ，攻击者改成 false 再放行，系统误以为修改失败，实际密码已经被改了。支付回调接口返回 {"payStatus":"fail"} ，改成 "success" 就能不付钱下单。

根源是同一个：后端在返回身份信息给前端后，默认前端不会再改它。但实际上，离开服务器后的任何数据，攻击者都可以随意篡改。前端发起的任何请求，攻击者都可以重新构造。信任链在HTTP响应体离开服务器的那一刻就断了。

五、怎么防

后端解密运营商token拿到手机号后，不要直接返回给前端。直接在服务端完成登录逻辑，生成一个Session ID或Token，只把这个Token返回给前端。前端拿到Token后，用Token去请求用户信息。用户信息接口从Token里解析用户ID，再去数据库查对应的手机号返回。整个流程里，手机号只出现在服务端，不经过前端传递。

把“身份验证”和“登录执行”放在同一个服务端事务里完成。不要分两步——先返回手机号，再让前端调用登录接口。直接在第一个接口里完成token解密、用户查询、Session生成，只返回一个token给前端。前端永远不接触手机号明文。

后端永远不要信任客户端传入的身份标识。 userId 、 phoneNumber 、 openId 这些字段，只能从服务端的Session或Token中读取。客户端传来的任何身份信息，都视为不可信输入。

审计清单：检查所有登录、注册、绑定手机号、找回密码的接口。确认没有一个接口是通过“响应体返回身份标识→前端再传给下一个接口”来实现的。如果有，改。

六、写在最后

一键登录本身是安全的，运营商token的加密强度没问题。问题在于开发者把“解密token”和“登录执行”拆成了两步，中间留了一个可以让攻击者篡改的窗口。这个窗口不在运营商那，也不在token里，就在从服务端到客户端的网络链路上。

phoneNumber ，改一下试试。你可能就登录了另一个人的账号。

这个漏洞没有技术含量，但它的危害是实打实的——直接绕过身份认证，以任意用户身份登录。在SRC里，这种洞基本定级高危，因为涉及任意用户登录。而你只需要一个Burp Suite，和一分钟的时间。

严正声明

本文所述技术仅供合法授权的安全测试使用。未授权拦截、篡改他人网络通信属于违法行为。所有案例均已脱敏，仅保留技术原理供学习参考。

本文出处： https://www.toutiao.com/article/7650925942478537250/

声明：文章版权归原作者所有部分文章转自互联网如有侵权请联系 [邮箱地址] 删除