文章总结： 该文档披露了一种云存储桶列对象绕过技术，通过构造特殊路径参数（如%2e和%3f）利用Prow系统接口缺陷，使S3签名路径被篡改为根目录，从而未授权获取Bucket文件列表。核心问题包括用户输入校验缺失、路径拼接逻辑缺陷及Bucket权限配置不当。文档提供了实际漏洞接口示例并指出修复方向。 综合评分： 85 文章分类： WEB安全,漏洞分析,云安全,实战经验

云存储桶可以实现列对象的一种绕过思路

原创

h1 h1

迪哥讲事

2026年5月1日 10:01 四川

在小说阅读器读本章

去阅读

云存储桶可以实现列对象的一种绕过思路

正文

1.这里使用一个公开的 Prow 实例作为示例（实际漏洞是在私有项目测试中发现的，无法披露）：

https://prow.falco.org

1.漏洞接口如下：

https://prow.falco.org/job-history/s3/falco-prow-logs/%2e%3f

Prow 原本只期望加载日志文本文件，并且会在 S3 URL 后自动追加 /latest.txt 进行签名。

但是：

通过传入 /.（即 %2e），可以访问 Bucket 的基础路径

通过编码的 ?（%3f），可以注释掉后面的 /latest.txt

因此最终被签名的 URL 实际变成：

s3://falco-prow-logs/.?/latest.txt 效果是：

实际签名的是 Bucket 根路径

返回的是整个 Bucket 的文件列表（类似目录 listing）

此外，这种技巧还可以读取任意文件：

https://prow.falco.org/job-history/s3/falco-prow-logs/any.valid.file%3f

注意其绕过手法

核心问题有 3 个：

（1）用户输入直接参与 S3 签名路径 Prow 提供了一个接口：

/job-history/s3/{bucket}/{path} 但：

{path} 没有做严格校验

用户可以构造特殊路径

（2）拼接逻辑存在缺陷

系统逻辑类似：

final_path = user_input + "/latest.txt" sign(final_path) 问题：

假设 user_input = .?\

实际 URL：

s3://bucket/.?/latest.txt 但：

? 在 URL 中是 query 分隔符

后面的 /latest.txt 被浏览器/服务端忽略

实际签名对象变成：

s3://bucket/.

（3）S3 Bucket 支持 List 操作

如果 Bucket 权限允许（常见于内部日志桶）：

GET / → 返回对象列表

结果：目录遍历（Bucket Listing）

五一假期来了，星球也已经运营三年多了，发个优惠券

参考

https://hackerone.com/reports/1485500

免责声明：

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

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

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

本文转载自：迪哥讲事 h1 h1《云存储桶可以实现列对象的一种绕过思路》