文章总结： 文章作者分享了两个实战案例：一是在某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
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：隐雾安全 隐雾安全
隐雾安全《【项目实战】我变成了个只会捡洞的垃圾》