记得刚开始学习Web安全时，老师总会强调：“越权漏洞和敏感信息泄露，是最好挖的漏洞。”
看着PPT上那些把 id=1 改成 id=2 就能获取他人数据的案例，我心中满是不屑：“这都202x年了，还有开发这么马虎？不校验Token？不检查权限？这种低级错误也能算漏洞？就这？”
那时我天真地认为，真正的漏洞挖掘应该是寻找0day、研究RCE、对抗加密算法。然而，现实很快就用两个生动的例子，狠狠教育了我。
注：本文所有涉及的目标与敏感信息均已脱敏，内容仅供安全研究与教学交流，请严格遵守法律法规，切勿用于非法用途。
第一记重击：改个数字，“接管”五千店主信息
一次在对某款App进行测试时，我注意到了它的“查询附近网点”功能。当时心想，这不就是个根据地理位置返回店铺名和经纬度的公开功能吗？能有什么危害？顶多算信息收集罢了。
抱着例行公事的心态，我随手抓取了一个看似平平无奇的数据包：
POST /api/getStoreInfo?id=1102
本来没抱什么期望，但手一抖，我还是点开了服务器的响应包（Response）。那一刻，我感觉自己看到了不该看的东西——简直是一场个人信息的“裸奔”。
响应包返回的JSON数据中，赫然包含着：
"ownerName": "王**" （店铺负责人的真实姓名）"phone": "139xxxxxxxx" （负责人的手机号）"idCard": "4201xxxxxxxxxxxxxx" （竟然连身份证号都明文返回了？）
一个大胆的猜测闪过脑海。我将请求参数中的 id=1102 随手改成了 id=1103，然后点击了“Send”。
没有任何阻拦，另一个完全不同的人的姓名、手机号和身份证号出现在了响应中。我接着尝试 id=799……结果同样如此。
至此，一个典型的ID遍历漏洞已经确认。我立刻祭出Burp Suite的Intruder模块，设置好载荷位置，让工具自动从 id=1 遍历到 id=5200。
最终，整个平台超过5200位店铺负责人的“姓名+手机+身份证号”全套敏感信息，就这样被我“合法”地遍历查询了一遍。对于黑产而言，这简直是送上门的“业绩大礼包”。这种因缺乏访问控制而导致的越权访问，在实际应用中比想象中普遍得多。
第二记补刀：连车牌和预约信息也未能幸免
尝到“甜头”后，我意识到这种低级但危害巨大的漏洞绝非个例。果然，在测试另一个车管相关的预约系统时，历史再次惊人地重演了。
在完成一次预约操作后，我查看了返回的成功数据包。又一个熟悉的剧本上演了——响应包中包含了当前预约的详细信息。
关键点在于，这个查看详情的请求，没有任何权限校验，也没有对查看他人订单做任何限制。我只需要修改请求中的订单ID参数，就能看到其他所有用户的预约详情。
再次启动Burp Intruder，对订单ID参数进行遍历攻击。瞬间，数万条包含车牌号、精准预约时间、车主联系信息的数据，如同开闸的洪水般哗啦啦地流淌出来。
某些系统中所谓的“安全防线”，在逻辑漏洞面前，脆弱得就像一张薄纸。以至于后来当我看到“某知名社区1570万条用户数据泄露”的新闻时，内心竟然毫无波澜。
只能希望泄露的数据里，没有你我的信息。
反思：为什么“低级”漏洞遍地都是？
在提交漏洞报告换取赏金的同时，我也在反思：自己是不是变成了一个只会“捡”这种简单漏洞的“垃圾”？挖这些洞，除了换取报酬，对技术提升真的有帮助吗？
揉着被现实打肿的脸，我终于悟了。
过去我认为的漏洞挖掘，必须是高精尖的：0day、远程代码执行（RCE）、加解密对抗。但现在我发现，现实中暴露最多、危害最直接的，往往是这些“不起眼”的：验证码回显、ID遍历、越权查询、业务逻辑缺陷。
为什么？
因为 “功能第一，安全第二” 是许多项目，尤其是业务压力大的项目，心照不宣的潜规则。
当安全研究人员在思考如何绕过复杂的WAF规则时，忙碌的业务开发工程师可能会想：“这不过是个查询附近网点的接口，哪个用户会无聊到去改ID玩啊？”
不好意思，我们安全测试员，就是那个“无聊”且专业的“傻子”。我们的工作，正是要发现并修复这些被忽略的“理所当然”，而像云栈社区这样的技术交流平台，正是沉淀和分享这些实战经验、共同提升防御水位的好地方。
通过这两个案例，我们可以清晰地看到，缺乏有效的身份认证和授权校验，是导致大规模敏感信息泄露的根源。安全建设必须贯穿于软件开发的整个生命周期，而非事后补救。
发表于 2026-2-11 08:08:26
|
查看: 25|
回复: 0
