如何找出真实存储桶名和 AK

RaunakGupta
RaunakGupta

漏洞集萃

2026年8月18日 08:58
山东

在小说阅读器读本章

去阅读

本公众号所发布的文章内容仅供学习与交流使用，禁止用于任何非法用途；如有侵权烦请告知，我们会立即删除并致歉，谢谢

在测试一个私有漏洞赏金计划时，我遇到了一个

作者: RaunakGupta
原文链接: https://medium.com/@RaunakGupta1922/the-leaky-bucket-bug-aa725b031cc5

目标概述

“目标概述”与该漏洞无关，因为该漏洞是在测试应用程序的静态资源时发现的。

现在进入正文

在随意测试一些端点时，我发现了一个托管在该域名上的文件 redacted.com.

该文件是从亚马逊 S3 存储桶中提供的，但当我直接访问时，却收到了一条简单的“访问被拒绝”错误提示。此时一切看似正常。

按回车键或点击查看大图

出于好奇，我在请求中附加了一个 jsessionid 参数。出乎意料的是，这次的响应截然不同。请求并未直接被拒绝，而是触发了亚马逊的Signature V4签名流程；由于签名不匹配，错误信息透露出的细节远超预期。

冗长的XML响应内容如下：

AWS 访问密钥 ID

（部分内容）。
* 所使用的签名算法。
* 该区域（us-east-1).
* 最重要的是，S3 存储桶名称 → redacted-www-live.

按回车键或点击查看大图

在请求中附加了一个 jsessionid 参数。
后端（或 S3 前端的代理）并未直接拒绝请求，而是尝试使用 AWS Signature v4 对请求进行签名。
由于我的 jsessionid 与应用程序预期的不匹配，请求因 SignatureDoesNotMatch 错误而失败。
但此次失败在 XML 错误中返回了调试详细信息：
AWSAccessKeyId（部分暴露）。
StringToSign 和 CanonicalRequest（显示签名过程）。
Host 头 → XXXXXXXXX.s3.amazonaws.com。
→ 这直接泄露了 S3 存储桶名称（XXXXXXXX）。