文章总结： 本文揭示一键登录功能中因后端直接返回手机号至前端导致的安全漏洞，攻击者可通过拦截响应包篡改phoneNumber字段实现任意用户登录。文章结合真实案例演示利用BurpSuite进行响应包篡改、越权获取全量用户数据的攻击链，并指出问题本质是后端错误信任前端传递的身份标识。最后提出防御方案：服务端应完成完整登录事务仅返回token，避免身份信息经前端传递。 综合评分： 85 文章分类： 渗透测试,WEB安全,漏洞分析,实战经验,安全建设

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

原创

逍遥 逍遥

昆仑AI安全实验室

2026年6月14日 00:36 广东

在小说阅读器读本章

去阅读

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

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

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

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

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

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

一键登录是运营商提供的“网关认证”能力。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里，就在从服务端到客户端的网络链路上。

下次测APP，看到一键登录按钮，别习惯性地跳过。打开Burp，点一下登录，看看返回包。找到那个phoneNumber，改一下试试。你可能就登录了另一个人的账号。

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

严正声明

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

欢迎加入知识星球让我们一起AI安全的路上互相探讨进步

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：昆仑AI安全实验室 逍遥 逍遥《一键登录的致命缺陷：拦截返回包改个phoneNumber，我就登录了你的账号》