在对一家印度公司的应用程序进行例行安全测试时，我意外发现了一个严重的数据泄露漏洞。该漏洞导致大量敏感的支付日志和个人身份信息(PII)被公开暴露，任何知晓访问方法的人均可获取。
通过一个未受保护的公开端点，攻击者能够直接查阅历史支付记录，内容涵盖客户邮箱、电话号码、IP地址、订单详情、支付状态与金额等关键信息。更危险的是，仅需修改URL中的一个日期参数，即可访问跨度长达数年的数据，极大地放大了信息泄露的规模与影响。
此漏洞的利用门槛极低，无需任何身份验证或高级攻击技巧。一个公开的端点，便足以让多年积累的客户与交易数据一览无余，对用户隐私、企业安全及合规性构成重大威胁。
本文将复盘整个发现过程，内容包括：
- 在自动化安全测试中如何识别敏感数据泄露
- 被公开的支付数据与个人身份信息类型分析
- 攻击者如何以最小成本访问海量历史日志
- 此类漏洞为何会引发数据泄露、金融欺诈与合规风险
- 保护支付系统与后端日志的关键安全经验
漏洞发现：始于一次例行测试
整个过程始于对自动化渗透测试脚本的验证。我与朋友正在开发一款旨在集成子域名发现、爬取与模糊测试等任务的自动化侦察脚本，以提升效率、减少人工干预。为了测试脚本效果，我们选择在VPS上对几个真实目标进行试运行。
脚本执行完毕后，我并未满足于表面的结果，而是深入检查其输出目录，特别是爬取与模糊测试生成的原始端点列表。这里潜藏着有待发掘的“数据宝藏”。
我使用grep等工具对结果进行模式匹配筛查，试图找出不寻常的端点。大多数是常见的静态资源或API路由，但其中一个特殊的端点引起了我的注意。其URL结构为 /payment/<已脱敏>/logs/day-year.txt，这看起来并不寻常。出于好奇，我在浏览器中直接访问了它。
结果令人震惊：页面直接显示了来自第三方支付服务商的原始支付日志。更关键的是，当我尝试修改URL中的“day-year”参数时，返回的数据也随之变为对应日期的全新日志。这表明，我发现的并非一个孤立文件，而是一个按日期归档的、庞大的日志文件系统入口。
随着进一步探索，情况变得更为严重。在另一次模糊测试的结果中，我发现了另一个遵循相同 /logs/day-year.txt 模式的端点。但此次泄露的数据层级更高：它包含了完整的API交易记录。
泄露的信息详尽得可怕，包括客户姓名、邮箱、手机号、地理位置坐标、时间戳以及完整的支付明细。所有这些数据在没有任何身份验证或访问控制的情况下公开暴露。通过简单地遍历年份参数，我能够访问从2010年至2024年的记录。初步估算，受影响的记录条数在5000万至9000万之间，可能波及近十年来的海量用户。
在确认漏洞的严重性后，我立即停止了测试，并遵循负责任的漏洞披露流程，整理了详细的技术细节与概念验证(PoC)，将报告提交给了该公司的安全团队。他们在数日内确认了漏洞的有效性，并给予了相应的漏洞赏金。
核心教训与反思
这次经历带来了一个深刻的网络安全启示：最严重的漏洞未必藏匿于复杂的攻击链之后。它们有时就隐藏在显而易见的自动化输出结果里，等待着那些愿意细心查看、追踪模式并提出简单问题（例如“如果我更改这个参数会怎样？”）的人去发现。耐心、好奇心和对细节的关注，其威力往往胜过任何高级工具。
此外，它也凸显了在安全测试中，对自动化侦察脚本的输出进行深入人工分析的重要性。自动化可以高效地收集海量数据，但最终的价值判断与深度挖掘，仍离不开安全研究员的关键性思维。严谨、负责任的漏洞披露，是连接安全发现与真实世界风险修复的桥梁，能够切实保护用户数据免受侵害。 | 
发表于 6 天前
|
查看: 21|
回复: 0
