红蓝对抗实战：API响应未脱敏与ID遍历导致的信息泄露

在授权进行红蓝对抗或安全测试时，我们常会遇到一些看似简单的官网或信息展示系统。这类站点功能通常不多，前端页面也较为静态，导致测试人员容易快速浏览后便将其忽略。

然而，正是这种“简单”的错觉，可能让我们与重要的安全漏洞失之交臂。问题的核心往往不在花哨的前端交互，而在于后端API的数据处理逻辑。

以一个实际的授权测试目标为例。系统中有一个“人员信息”查询功能，用户在前端界面点击查看某人的“基本信息”时，页面展示如下：

从用户界面（UI）上看，仅展示了姓名和部分隐藏的电话号码，似乎已经做了基本的脱敏处理，信息敏感度不高。许多测试者可能至此便认为无进一步测试价值。

但后端API返回的原始数据却可能大不相同。通过抓包工具拦截该查询请求的响应，我们发现了真相：

响应体是一个完整的JSON对象，其中list字段包含了详细的个人信息。与前端展示的寥寥数项不同，这里直接返回了姓名、性别、完整身份证号、联系电话、住址等高度敏感的个人信息，且完全未做任何脱敏处理。这就是典型的前后端脱敏不一致导致的信息泄露漏洞。

更值得警惕的是，此类接口往往伴随着ID参数遍历的风险。观察请求，发现其通过一个简单的id参数（如{“id”:96}）来获取指定人员信息。攻击者只需简单地递增或递减这个id值，即可批量获取系统中所有人员的完整敏感信息，造成大规模数据泄露。

因此，在进行安全测试时，面对任何查询、展示类功能，决不能仅凭前端渲染内容来判断安全性。必须养成习惯，深入检查后端API的原始响应：

1. 对比前端与后端数据：查看API返回的JSON或XML数据是否包含了超出前端展示范围的敏感字段。
2. 检查脱敏一致性：前端脱敏的字段，在后端数据中是否真的被移除或替换。
3. 测试参数可遍历性：对id、userId、page等参数进行修改，测试是否存在未授权访问其他数据的情况。

这类漏洞原理简单，却极易在快节奏的测试中被忽略。它提醒我们，漏洞有时就藏在最常规的交互之下。保持对数据流的敏感，不放过任何一个API请求与响应，是发现此类“简单粗暴”却危害巨大的信息泄露漏洞的关键。在云栈社区中，也有许多关于如何系统性进行API安全测试的讨论与分享，值得深入探讨。