文章总结： 本文介绍在私有漏洞赏金计划中，通过向S3请求添加jsessionid参数，触发AWSSignatureV4签名流程，导致错误响应泄露存储桶名称和部分AK。关键发现是配置错误可被利用进行侦察，建议安全处理错误消息并限制调试信息泄露。 综合评分： 81 文章分类： 漏洞分析,云安全,渗透测试

如何找出真实存储桶名和 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）。

为何这很重要

通常情况下，用户只会看到一条简单的“访问被拒绝”提示。但由于此配置错误，只需在请求中追加一个参数（jsessionid）就迫使后端以不同方式处理该请求，从而泄露了内部 AWS 存储的详细信息。

虽然这可能无法直接导致系统完全被攻破，但此类信息泄露对攻击者进行侦察非常有用，并有助于串联利用更严重的漏洞，例如桶接管或权限提升。

经验总结

1. 切勿依赖默认的错误处理机制来处理带签名的请求。
2. 始终对向最终用户展示的错误消息进行安全处理并加以限制。
3. 即便是简单的参数更改，也可能暴露关键的内部细节。

觉得本文内容对您有启发或帮助？ 点个关注➕，获取更多深度分析与前沿资讯！

👉 往期精选

逻辑漏洞：邮箱注册 tips #11

非常用403绕过 Tips

Android IPC 漏洞利用系列

新技术绕过文件上传

免责声明：

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

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

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

本文转载自：漏洞集萃 RaunakGupta RaunakGupta《如何找出真实存储桶名和 AK》