本文仅供技术学习与交流，请勿利用相关技术从事非法测试。一切后果由使用者自行承担。
在一次针对某服务平台的授权数据专项检查中，客户的核心诉求是探查是否存在预想之外的敏感信息泄露风险。接到这种“寻找意想不到的漏洞”的任务，往往需要一些逆向思维和细致的观察。
目标系统是一个典型的在线服务平台，具备登录、注册等基础功能。我的第一步永远是先注册一个测试账号，按照正常用户的路径走一遍全流程，摸清各个功能模块。
在逐一测试功能点时，“申报事项”这个模块引起了我的注意。这类涉及信息提交与查询的环节，往往是逻辑漏洞的高发区。于是，我立即填写了一条测试数据并提交。
提交成功后，系统果然提供了一个“申报事项查询”功能。根据页面提示，需要输入姓名和身份证号才能查询相关办件进度。这看起来是一个标准的、需要身份验证的查询入口。
下一步自然是抓取这个查询动作的数据包。通过抓包工具，可以看到这是一个向 /query 接口发起的 POST 请求，其请求体 JSON 结构大致如下（敏感信息已脱敏）：
{"powerid":"[redacted]","sbr":"[redacted]","sfzh":"[redacted]","pageNum":1,"pageCount":16}
经典的测试思路又派上用场了。这里会不会存在未授权访问的问题呢？一个直接的测试方法是：尝试将请求参数中的姓名 (sbr) 和身份证号 (sfzh) 字段置空，或者尝试只置空其中一个，看看后端逻辑是如何校验的。这种测试本质上是在试探开发人员留下的逻辑疏漏。
我将相关参数置空后再次发送请求，服务器的响应令人意外——它没有返回错误，而是直接返回了系统中大量的办件ID (fid) 列表。
这意味着，攻击者无需知晓任何人的姓名和身份证号，就可以批量获取到系统内所有正在进行或已完成的业务办件标识符。获取到这些 fid (办件ID) 后，危险才刚刚开始。
紧接着，我找到了一个查看办件详情的接口（例如 /apply/[fid]）。只需将上一步获取到的任意一个 fid 填入请求中，即可直接查询到该办件关联的所有敏感信息。
从响应中可以看到，接口返回了申报人的姓名、身份证号 (sfah)、联系电话 (sbsj)、住址等极为敏感的个人信息。至此，一个完整的、因业务逻辑缺陷导致的敏感信息泄露链就被清晰地挖掘了出来：未授权批量枚举办件ID -> 通过ID未授权访问详细信息。
这种漏洞的根源在于后端服务在关键查询接口上缺少严格的权限校验。前端看似要求输入身份信息，但后端接口却完全依赖于客户端传来的参数，并未在服务端会话或Token层面验证当前用户是否有权查询这些数据。这是一种在安全/渗透/逆向测试中需要重点关注的问题。
整个测试过程并不复杂，关键在于对业务流程的熟悉和对开发者可能犯错的地方保持直觉。希望这个案例能给大家在业务逻辑漏洞挖掘上带来一些启发。如果你有更多有趣的思路或案例，欢迎在云栈社区与大家交流探讨。 | 
发表于 14 小时前
|
查看: 2|
回复: 0
