2026-04-13 05:07:53 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文通过5个真实案例详细展示了个人身份信息（PII）泄露的常见途径，包括API模糊测试发现未授权的员工审核端点、静态文件搜寻找到泄露的外交联系人PDF、服务器端脚本直接暴露用户数据、网络档案挖掘出访问令牌与注册表信息，以及通过逻辑推理发现大学学生数据端点。文章指出根本原因在于API缺乏身份验证与授权、敏感文件公开存放、后端脚本可直接访问、URL中嵌入令牌等问题，建议开发者为所有数据端点实施认证与授权控制，并阻止脚本直接访问。 综合评分： 82 文章分类： 渗透测试,数据泄露,WEB安全,SRC活动,漏洞分析

cover_image

我发现的5种个人身份信息泄露案例：真实案例研究

haidragon haidragon

安全狗的自我修养

2026年4月10日 12:15 湖南

官网：http://securitytech.cc

#

嘿，黑客们，

在漏洞赏金领域，个人身份信息（PII）泄露往往被低估。人们热衷于寻找跨站脚本（XSS）和远程代码执行（RCE）漏洞，但大规模泄露他人的电子邮件地址、电话号码、家庭住址或内部ID，其影响同样巨大，有时甚至更甚。仅凭欧盟《通用数据保护条例》的罚款就足以说明问题啦！

这五个案例涵盖了多种攻击面：API模糊测试、静态文件搜索、服务器端脚本、网络存档挖掘，以及老派的浏览器好奇心。让我们一起来看看吧。

案例研究1：API模糊测试：当 `/api/v1/reviews` 泄露整个员工目录时

它起步的方式和大多数事情一样，先是试探了一下API。目标的REST API结构看起来相当标准，地址是 https://reviews.[REDACTED]/api/v1。我决定用ffuf对端点路径进行模糊测试，看看应用表面之外还隐藏着什么内容。

1. ffuf&nbsp;-u https://reviews.[REDACTED]/api/FUZZ -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt -mc 200ffuf -u https://reviews.[REDACTED]/api/v1/FUZZ -w /usr/share/seclists/Discovery/Web-Content/common.txt -mc 200

你可以在这里使用任何词汇表。SecLists 提供了针对特定 API 的可靠词汇表。我们的目标是找到开发者从未打算公开，或干脆忘记加以保护的端点。

我发现的

在这些结果中，/api/v1/reviews 返回了 200OK。我在浏览器中打开它，却发现并没有呈现整齐的分页界面，而是一堆原始的 JSON 数据。而且，这不仅限于评论得分。数组中的每个对象包含：

id：一个唯一标识评审条目的UUID
userId：员工电子邮件地址（例如： [email protected]）
review.score 和 review.text：内部绩效或服务评价内容
target.type: "employee"，确认这是内部人力资源/评审数据
target.companyId、 employeeId、 transactionId：每个员工的多个唯一标识符
createdAt：每次提交评论的时间戳

该端点未经过身份验证。无需令牌、Cookie 或身份验证头。只需访问该URL，即可浏览该公司员工的完整审核历史。

按Enter键或单击以查看完整尺寸的图片

经验教训

这里的一个经典错误是，将内部API端点视为“隐藏”而非“受保护”。通过模糊测试进行发现轻而易举。任何返回敏感数据的端点都必须进行身份验证和适当的授权检查。就这么简单。修复方法也很直接：要求提供有效的会话令牌，并验证请求用户是否具备读取该数据的权限。

案例研究2：静态文件搜寻：一份泄露了外交联系人名单的PDF文件

静态文件是一片金矿，一旦猎人越过基础侦察阶段，往往会忽略它。诸如 .pdf、 .xls、 .csv、 .json、 .doc、 .xlsx、 .txt、 .xml之类的文件，往往会被爬虫频繁索引，并在组织自以为已彻底清理干净后，仍被像时光机和GAU这样的工具长期存档。我的工作流程如下：

1. # 拉取所有已知的URL

3. gau target.com&nbsp;|&nbsp;tee all_urls.txt

5. waybackurls target.com&nbsp;>>&nbsp;all_urls.txt

7. cat all_urls.txt&nbsp;|&nbsp;sort&nbsp;-u&nbsp;|&nbsp;tee unique_urls.txt

1. # 筛选多汁的静态文件扩展名

3. cat unique_urls.txt&nbsp;|&nbsp;grep&nbsp;-iE&nbsp;"\.(pdf|xls|xlsx|csv|doc|docx|json|xml|txt|bak|sql)(\?|$)"

然后，我手动访问每个页面，或者使用一个小脚本检查哪些页面仍返回“200 OK”。

我发现的

一份PDF文件立刻脱颖而出。这是一份7页的文档，公开存放在目标服务器的 /files/nf[REDACTED]021.pdf路径下。

常驻代表团：这些个人所代表的组织或代表团
姓名：全名，部分条目列有多个代表
电子邮件：直接电子邮件地址（ .gov、 .int、 .org 域名）
信息：职位名称与角色（主任、秘书、使团负责人等）

这是一份联系人名录，本质上是一个仅供外交或机构内部人员使用的通讯录，本不该对外公开。

第二份文件更是令人震惊。这是一份长达4页的内部安全审计报告，其中包含一张编号的漏洞跟踪表，该表设有漏洞名称、描述、状态（已解决、已修补、已移除、非漏洞、待检查与测试）以及日期等列。一些漏洞被列为未解决或仍需测试。

按Enter键或单击以查看完整尺寸的图片

经验教训

文件并不会因为您从网站上删除了链接就消失。如果谷歌、时光机或任何爬虫曾对其进行过索引，这些文件就会被保留下来。敏感文档绝不能存放在未经身份验证的公共可访问的Web服务器上。至于包含未修复漏洞的内部安全报告？这无异于直接向攻击者提供一份路线图。

案例研究3：服务器端脚本文件： `getAllInformations.php` 的功能与名称完全一致

这次测试的关键在于针对特定扩展名过滤器的文件和目录模糊测试。大多数模糊测试都使用通用的单词列表，但当你在ffuf或dirsearch的运行中添加 -e.php（或 .jsp、 .asp、 .aspx）时，就能开始发现开发者遗留下来的后端脚本。

1. # 使用带有PHP扩展过滤器的ffuf

3. ffuf&nbsp;-u https://[REDACTED]/FUZZ -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -e .php -mc 200

1. # 或者使用dirsearch

3. dirsearch&nbsp;-u https://[REDACTED]/ -e php,asp,aspx,jsp -t 40

你也可以为此使用Google高级搜索语法：

1. 站点：target.com&nbsp;文件类型：php

3. site:target.com ext:php inurl:admin&nbsp;或&nbsp;inurl:lib&nbsp;或&nbsp;inurl:api

我发现的

浮现的端点是 https://[REDACTED]/fact_demat/lib-php/getAllInformations.php。仅凭这个名字就已足够引人警觉。“getAllInformations”这个名字毫不隐晦。

在浏览器中访问时，返回的是未经分页的原始数据转储。该响应是一个密集的类似JSON的结构，其中包含看似数十个个人和实体的记录，包括：

完整的电子邮件地址（个人 @gmail.com、 @yahoo.com 以及公司域名邮箱）
数字ID（每个条目中的“num”字段，顺序标识符）
姓名与组织隶属关系

该页面以纯文本形式呈现，完全未应用任何样式。这是一个后端数据获取脚本，原本并不打算通过浏览器直接访问，但却完全没有访问控制机制。

按Enter键或单击以查看完整尺寸的图片

经验教训

如果PHP及其他执行数据库查询的服务器端脚本文件并非作为具备身份验证的正规API的一部分，切勿直接通过网络访问。这些文件通常位于实用程序或库文件夹中（如 /lib-php/、 /includes/、 /helpers/），开发者往往以为这些文件不会被猜到，但终究还是会被猜到。解决这一问题的方法包括：合理配置 .htaccess规则、通过Web服务器配置阻止直接访问脚本，以及最重要的是，在所有涉及数据库操作的代码中引入身份验证中间件。案例研究4：网络档案挖掘——存档URL中隐藏的访问令牌与个人数据

时光机及类似服务不仅存档网页，还存档API响应、URL参数和查询字符串。这使得它们成为一座被动侦察的宝库。尤其是CDX API，可让你以编程方式提取某个域名的所有已归档URL。

1. waybackurls target.com&nbsp;|&nbsp;tee wayback_output.txt

3. gau&nbsp;--subs target.com&nbsp;|&nbsp;tee gau_output.txt# 然后使用grep查找感兴趣的模式

5. cat wayback_output.txt&nbsp;|&nbsp;grep&nbsp;-iE&nbsp;"(api|uuid|token|key|auth|admin|register|user)"

我发现的

对目标执行CDX搜索后，出现了一长串已归档的URL，这些URL立刻引起了我的注意：

1. /api/评估员注册中心/状态

3. /api/评估员注册表?pageNumber=1

5. /api/呼号注册表？搜索=&分页号=1

7. /api/呼号注册表？搜索=&页码=2

9. /数据可视化？workspaceId=7ffb2a9e-0bec...

11. /数据可视化？workspaceId=eb3...

有两点尤为突出。首先， AssessorRegistry 和 CallsignRegistry 这两个端点看似面向公众的注册表，但访问它们却会暴露完整的个人身份信息（PII）转储。/api/AssessorRegistry/ 端点返回了一个分页的个人列表，其中包含：

fullName: 完整姓名
advertisedAddress：完整的家庭或企业地址（郊区、州、邮政编码、国家）
advertisedEmail：个人和企业电子邮件地址
advertisedPhone：直接电话号码
type: 账户分类

其次，带有UUID的 /Datavis?workspaceId=参数似乎用于仪表板共享。点击其中一个已归档的工作区ID，会返回一个JSON响应，其中包含一个实时访问令牌——一种可用于对平台其他部分进行身份验证的长有效期持有者令牌，以及一个 embedUrl和 reportId。

按Enter键或单击以查看完整尺寸的图片

经验教训

网络档案不会遗忘。即使某个组织更换了令牌或下线了某个端点，嵌入了令牌或在响应中返回的已归档URL仍可能有效，至少能揭示认证机制的运作方式。基于UUID的工作区ID若未附加额外授权，简直就是一场蓄势待发的IDOR漏洞。而那些暴露完整联系信息且无需任何身份验证的注册表？这至少直接触犯了GDPR的规定。案例研究5：浏览器好奇心与模式识别：一所大学的学生数据隐藏于显而易见之处

发现

这与其说关乎工具，不如说更关乎留心观察。我正在浏览一所知名大学的子域名时，偶然进入了一个位于 /dictaten 的页面。该页面呈现为一种简洁的卡片式界面，列出了看似课程或模块名称的内容： datab1、 datab2、 DataEngineeringWorkshops、 DesignPatterns1、 Engelsjaar3、 English5、 English6、 FAQdataanalyse……名单还在继续。

每张卡片下方都有一条遵循以下模式的网址：

1. [已删除]/听写/数据1

3. [已删除]/听写/英语5

我点开了几个。它们加载了一些前端课程内容，没什么敏感信息，都是些正常的东西。但命名规范让我产生了一个念头：如果存在一个名为datab1的前端UI界面，那么这个系统是不是在某个地方存储着参与者或注册数据呢？

浮现在脑海中的词是“参与者”。调查平台、竞赛系统、电子学习工具，几乎无一例外都包含“参与者”这一概念。于是，我尝试了一下：

1. [已删除]/记录/数据1/参与者

3. [已删除]/听写/英语5/参与者

两者都返回了 JSON。没有身份验证提示。没有重定向到登录页面。只是原始的、开放的 API 响应。

每个课程的响应结构包括：

id：每个学生的UUID
name: 学生全名
userName：学生用户名（部分直接以电子邮件地址形式暴露，例如 [email protected]）
email：电子邮件字段（部分为空，部分有值）
group: 课程或学习小组分配（A、B、C、F、H、M……）
points：课程的数值评分
isTeacher: 布尔值（用于确认学生与员工的区分）

该端点正在枚举每门课程中的每一位参与者，而这家大学似乎拥有规模庞大的学生群体。

按Enter键或单击以查看完整尺寸的图片

经验教训

没有工具能发现这一点。词典列表也未找到它。但逻辑推理却发现了。当你了解应用程序的结构——比如课程管理系统很可能包含用户，而课程中的用户通常被称为参与者时，你就能手动构建出开发者已实现却从未通过用户界面公开的端点。而这正是自动化扫描器完全遗漏的一类漏洞。

缓解措施（面向开发者）

在所有五个案例中，根本原因都归结于以下几个相同的错误：

API端点无需身份验证：所有返回用户数据的端点均需具备有效且已验证的会话。
公共Web服务器上的敏感文件：包含个人身份信息或内部安全数据的文档绝不能在未实施访问控制的情况下直接从Web根目录提供服务。
直接访问服务器端脚本：后端脚本不应可通过浏览器直接访问。应使用路由中间件，并在Web服务器级别阻止对文件的直接访问。
URL中的令牌和ID：嵌入在URL中的访问令牌可能会被存档、记录并泄露。请改用POST主体和授权头。
子资源缺少授权：仅进行身份验证（证明你是谁）是不够的；必须针对每个资源强制实施授权（证明你有权查看此数据）。

公众号:安全狗的自我修养
vx:2207344074
http://gitee.com/haidragon
http://github.com/haidragon
bilibili:haidragonx

#

免责声明：

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

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

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

本文转载自：安全狗的自我修养 haidragon haidragon《我发现的5种个人身份信息泄露案例：真实案例研究》