文章总结： 文章作者分享了两个实战案例：一是在某App查询网点接口中通过遍历ID参数获取5200多名店主的姓名、手机号和身份证号明文；二是在车管系统中同样通过ID遍历获取数万条车牌号、预约时间和车主信息。作者反思认为，虽然这类越权/敏感信息泄露漏洞技术门槛低，但现实中因开发优先考虑功能而忽视权限校验，导致此类问题大量存在，是SRC赏金的主要收入来源。 综合评分： 72 文章分类： SRC活动,渗透测试,漏洞分析,安全运营,实战经验

【项目实战】我变成了个只会捡洞的垃圾

原创

隐雾安全 隐雾安全

隐雾安全

2026年2月10日 09:02 四川

📝 编者语

记得刚学Web的时候，老师讲：“越权漏洞和敏感信息泄露，是最好挖的漏洞。”

我看着PPT上那些 id=1 改成 id=2 的案例，心里全是轻蔑： “这都 202x 年了，哪还有开发这么傻？不查 Token？不校验权限？这种低级错误也能叫漏洞？就这？”

“老子要挖的是0day”。 然后，现实狠狠地给了我两个大逼兜。

(注：本文所有敏感信息已脱敏，仅供安全研究与教学交流，请勿用于非法用途。)

1

第一巴掌：改个数，就“接管”5000个老板

那天在测试一个 App 的“查询附近网点”功能。

这功能不就是返回个经纬度和店铺名吗？

这种公开信息能有啥危害？

顶多算个信息收集吧？

随手抓了一个看起来平平无奇的数据包： POST /api/getStoreInfo?id=1102

手一抖，点开了响应包（Response）。 那一刻，我感觉我看到了不该看的东西——实名制裸奔现场。

响应包里写着：

• “ownerName”: “王**”（店主真实姓名）
• “phone”: “139xxxxxxxx”（店主手机号）
• “idCard”: “4201xxxxxxxxxxxxxx”（身份证号明文返回了？）

把请求参数里的 id=1102 改成了 id=1103。 “Send”。

毫无阻碍，另一个人的身份证号和手机号跳了出来。 再改成 id=799… 又是另一个人的。

从 id=1 遍历到 id=5200。 全站 5200 多位店主 的 姓名+手机+身份证，就这样被我“合法”地查了一遍。

这简直就是给黑产送业绩啊！

2

第二巴掌：连车牌号都不放过？

这么简单我不得多捡几个啊，都是真金白银啊！

历史总是惊人的相似。

测试目标里刚好有一个车管系统

我在预约成功的返回包里，又看到了那个熟悉的字段

没有任何权限校验，也没有对查看他人订单做任何限制。 我再次祭出 Burp Intruder，对参数进行了一波遍历。 几万条车牌号、预约时间、车主信息，像流水一样哗啦啦地流了出来。

所谓的“安全”，在某些系统里，脆弱得像一张纸。以至于我看到这条消息的时候，内心毫无波澜

希望没有你我的表哥。

3

真“香”

我一边沉浸在赚到赏金的喜悦中，一边又忍不住自我批判。

你变了，变成了一个只会捡洞的垃圾。

挖这些洞有什么意义呢？

除了能换几两碎银对我的技术提升有什么帮助呢？

揉着被打肿的脸，我终于悟了

以前觉得漏洞挖掘必须是：

0day、RCE、AES解密、高级对抗。

现在发现，现实暴露出最多的漏洞往往是：

验证码回显、ID遍历、越权查询、逻辑裸奔。

为什么？

因为“功能第一，安全第二” 是很多项目的潜规则。 当我们在研究怎么绕过WAF的时候，

开发可能觉得：

“这就一个查网点的接口，那个傻*会无聊到去改ID玩啊？”

不好意思，我就是那个傻*。

🎁 文末福利

联系客服获取《海角社区警告》

!

微信号丨Hiddenfog001

免责声明：

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

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

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

本文转载自：隐雾安全 隐雾安全 隐雾安全《【项目实战】我变成了个只会捡洞的垃圾》