一个没带Cookie的GET，我看到了1191万用户的钱包

原创

学点安全吃早餐
学点安全吃早餐

学点安全吃早餐

2026年8月25日 13:21
福建

在小说阅读器读本章

去阅读

没带 Cookie，一个 GET，返回包里躺着用户的虚拟资产字段。

最近挖企业 SRC 挖到一个挺有代表性的案例，想跟你聊聊。

对象是金融集团旗下的一家直播平台（归属某个大厂 SRC 收录资产）。

整个过程不复杂，没有 SQL 注入、没有 RCE、没有高深的绕过。

就一句：有个接口，完全不校验你是谁。

复杂的东西往往好看，但这类的杀伤力，一点不比它小。

01

一个不带认证的用户信息接口

接口路径很直白，getuserinfo，查用户信息。

我在请求里没放任何 Cookie 和 Token，直接打过去。

服务端没拦，正常返回了。

返回里最扎眼的是这些字段：coin（浪客币余额）、ticket（收礼总数）、send\_coin\_count（送礼总数）、profit（总收益）、cash\_coin（可提现余额）。

这不是普通资料，这是用户的账户虚拟资产。在直播这类业务里，浪客币、可提现余额，都是真金白银。

更麻烦的是，这个接口还顺带吐了手机号、主站的 UID、账号 ID。也就是说，平台的账户资产，能一路关联回金融集团主站的金融账号。

一个接口，等于把\"这人有多少钱\"和\"这人在金融 App 里是谁\"绑在了一块暴露。

02

真正吓人的是下一步

getuserinfo 要传一个 user\_id 才能查。

关键问题来了，这批 user\_id 从哪来？

我又顺手测了平台里的 SearchUser 搜索接口。同样，无需认证。

它返回的 count（用户总数）写得很清楚。

11,918,687。约 1191 万。

而且支持分页。page 从 1 往后翻，每页 10 条，能把这 1191 万条 user\_id 一条不剩地拉完。

SearchUser 无认证返回用户总数与全量分页遍历能力。

两个接口一拼，整条链路就闭合了：

SearchUser 全量拉 user\_id → 逐个喂给 getuserinfo → 批量读全部用户账户资产

两个都是零认证的 GET。任何一个懂 curl 的人，写个 for 循环就能拖库。

03

危害怎么证明

按企业 SRC 的规矩，证明到\"确实能拿到敏感数据\"就停，不真去拖全库。

所以我只按分页拉了几十条构建样本，挑高资产用户出来看。

结果里，靠收礼就能收到上千万（ticket 维度）的头部用户，一抓一个准。

下表的手机号、UID、资产数值我已按规范全部打码。你只需看两个信息：接口吐了什么字段，以及这些字段覆盖了多少维度。

证据表展示接口泄出的字段维度（表体敏感数据已打码）。

昵称、等级、手机号（脱敏）、主站 UID、账号 ID、收礼数、送礼数、地区、生日、学校、注册时间……

而且这还只是 getuserinfo 单个接口的年表。配上 SearchUser 的全量遍历，覆盖的是全部 1191 万用户。

04

修起来其实不复杂

这类漏洞的修复几乎没啥技术含量：

第一，getuserinfo 服务端强校验 CToken / UToken，无认证直接拒。

第二，未认证请求不下发 coin、cash\_coin、phone\_number、UID 这些敏感字段。

第三，SearchUser 这类遍历型接口，强制登录 + 限频，从根上掐掉批量拖库。

四行字。难的不在写代码，在于想没想到\"接口得信调用方\"这件事上。

05

两句闲话

企业 SRC 挖久了会发现，最容易翻船的地方，往往不在那些花哨的绕过手法里。

而在\"接口默认相信调用方\"这一行没写出来的约定上。

只要调用方是\"你\"，就什么都不验。

对直播平台，是用户的虚拟资产；对金融属性的平台，那可就是用户的钱袋子。

每一次\"没带认证也先测一下\"，都是把这条默认信任翻出来晒一遍。

多试一次不亏。

本文为授权范围内的企业 SRC 测试记录，图片内个人字段均已打码脱敏，请勿用于任何未经授权的用途。