文章总结： 对象存储BucketPolicy过度授权导致域名被用于钓鱼攻击，攻击链包括公开写上传恶意页面、公开读枚举内部文档及策略越界接管资产。核心结论是默认拒绝按需放行，建议开启BlockPublicAccess、禁止Principal为*、关闭ListBucket并实施最小权限与监控审计。 综合评分： 92 文章分类： 云安全,数据安全,漏洞分析,安全建设,实战经验

你的对象存储，正在替黑客养鱼：Bucket Policy过度授权+公开写，我把钓鱼页面传到了你公司官网上

原创

www.klsec.com www.klsec.com

昆仑AI安全实验室

2026年9月11日 18:04 广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

上个月测一家企业的官网，我在他们的对象存储Bucket里上传了一个HTML文件，访问后弹出一个“IT部门安全更新”的登录页，把公司Logo和域名都原样搬了上去。这个页面的URL是https://assets.company.com/security-update.html，域名是他们的，证书是他们的，搜索引擎的信誉分也是他们的。

如果我把这个链接发给他们员工，告诉他们“请登录验证身份”，你觉得他们会点吗？

这就是Bucket Policy过度授权的可怕之处：它不只是数据泄露，它能把你的域名和信誉变成黑客的钓鱼工具。

今天这篇文章，不聊虚的。我会把Bucket Policy配置错误的根源、三种真实的攻击链、以及一套可以直接落地的最小权限配置清单，全部拆开。新手看完能理解云存储安全的逻辑，老手看完能直接拿去检查自己的配置。

一、先说清楚：Bucket Policy到底是怎么被配错的？

Bucket Policy是对象存储的“大门规则”。它用JSON定义“谁能在什么条件下对哪些资源做什么操作”。一个正确的Policy应该是“默认拒绝，按需放行”。但现实中，它经常被配成“默认放行，谁都能进”。

最常见的错误配置有三种：

错误一：为了方便CDN，把GetObject权限开给了所有人。

很多人为了让CDN能读取静态资源，直接把Policy写成：

{  "Effect": "Allow",  "Principal": "*",  "Action": "s3:GetObject",  "Resource": "arn:aws:s3:::company-assets/*"}

Principal: "*"意味着互联网上任何人都能读取这个Bucket里的所有文件。如果Bucket里存的是图片、JS、CSS，那还好说。但如果里面混进了备份文件、数据库导出、内部文档，那就是灾难。

错误二：为了让上传功能“能用”，把PutObject权限也开给了所有人。

更致命的错误。开发者在实现用户上传功能时，发现预签名URL“太麻烦”，于是直接给Bucket开了公开写权限：

{  "Effect": "Allow",  "Principal": "*",  "Action": ["s3:GetObject", "s3:PutObject"],  "Resource": "arn:aws:s3:::company-assets/*"}

这意味着任何人——不需要任何凭证——都可以往这个Bucket里上传任意文件。如果这个Bucket被用来托管网站静态资源（很多企业就是这么干的），攻击者可以上传一个恶意的index.html，直接替换掉你的首页。

错误三：ListBucket权限开放，让攻击者可以枚举你的全部资产。

有些团队觉得“我只开放读，不开放写，应该安全”。但如果你同时开放了ListBucket，攻击者就能列出Bucket里的每一个文件，包括那些你不希望别人知道的备份文件、内部文档、测试数据。

这三种错误经常叠加出现，一个比一个致命。

二、攻击链：从上传一个HTML文件，到接管你的域名

Bucket Policy过度授权的危害不是孤立的，它可以和对象存储的其他功能组合，形成完整的攻击链。

攻击链一：公开写 → 上传钓鱼页面 → 利用你的域名行骗

这是我开头提到的场景。攻击者发现你的Bucket开启了公开写权限后，上传一个login.html文件，内容是一个高仿的公司登录页面。然后构造链接https://assets.company.com/login.html，发给你的员工。

这个链接的所有特征都是“合法”的：域名是你的、HTTPS证书是你的、页面上的Logo是你的。员工点开后，输入账号密码，数据直接发到攻击者的服务器。

2026年3月，安全研究人员披露了一起利用Google Cloud Storage公开Bucket托管恶意HTML重定向器的钓鱼活动。攻击者在一个名为whilewait的公共GCS Bucket中放置了重定向文件，然后发送大量钓鱼邮件，所有邮件都指向storage.googleapis.com上的这个文件。受害者的第一跳看到的是Google的域名，心理防线瞬间降低，然后被重定向到伪造的登录页面。单个受害者的邮箱就收到了25封以上的钓鱼邮件，全部指向同一个GCS路径。

攻击链二：公开读 + ListBucket → 枚举内部文档 → 精准社工

即使没有写权限，只要开放了读和列举，攻击者就能用aws s3 ls --no-sign-request一条命令列出Bucket里的所有文件。然后逐一分析，找到有价值的文档。

我见过一个案例：某公司的Bucket里有一个onboarding/目录，里面存着新员工的入职材料模板，包括一份“IT账号申请流程.pdf”。PDF里写着公司内部系统的地址、默认账号格式、以及IT部门的联系方式。攻击者拿到这些信息后，伪造了一封“IT部门”的邮件，诱导新员工点击钓鱼链接。成功率极高。

2026年6月的一篇技术分析指出，一个配置为Principal: "*"的S3兼容Bucket，攻击者不仅能读取数据，还能上传恶意文件。如果这个Bucket被用来托管前端静态资源，攻击者上传一个恶意JS文件，就能在所有访问该网站的用户的浏览器中执行代码。

攻击链三：Bucket策略可写 → 修改策略 → 接管整个存储资产

这是最严重的情况。如果攻击者通过某种方式（比如泄露的AccessKey、SSRF获取的临时凭证）拿到了Bucket的策略修改权限，他可以把自己的Principal加进Policy里，或者直接修改Policy为“全公开”。

2026年8月，安全研究者披露了一个MinIO的权限边界缺陷（CVE相关）：IAM策略中的arn:aws:s3:::bucket/*原本只应该授予对象级操作（读、写、删某个文件），但由于匹配器对空对象名的处理缺陷，这条策略实际授予了桶级操作权限，包括PutBucketPolicy——也就是“修改桶策略”的权限。

这意味着：一个只被授予“读写某个桶里对象”权限的用户，可以修改桶的Policy，把它变成匿名公网可读可写，或者给自己授予桶级控制权。更可怕的是，同一个缺陷还允许DeleteBucket——直接删除整个桶。

这类漏洞的根源是权限模型的“越界”：你以为你只给了对象级权限，但实际上你给了桶级权限。攻击者可以利用这个越界，把整个存储资产变成自己的。

三、实战案例：三个真实场景的完整复盘

案例一：某SaaS平台的静态资源Bucket被公开写

该平台的前端静态资源（JS、CSS、图片）托管在AWS S3上，通过CloudFront分发。为了方便CI/CD流水线自动上传构建产物，运维把Bucket Policy配置成了公开读写。

我发现这个问题后，上传了一个test.html文件，内容是<script>alert(document.domain)</script>。访问https://cdn.platform.com/test.html，弹出了cdn.platform.com的域名。这意味着我可以利用这个Bucket托管任意HTML/JS文件，在用户的浏览器中执行代码。

如果我把这个页面伪装成“安全更新”或“登录验证”，就能窃取该平台用户的凭证。我提交了报告，定级高危，赏金几千块。修复方案是：移除公开写权限，CI/CD使用IAM角色（而不是公开Policy）上传。

案例二：某企业的日志归档Bucket可公开列举

该企业将所有应用日志归档到一个S3 Bucket，用于合规审计。运维在配置时，为了方便审计人员访问，开放了ListBucket和GetObject权限给Principal: "*"。

我使用aws s3 ls s3://company-logs-archive --no-sign-request，列出了Bucket里的所有文件。其中有一个hr/2026-08-15.log文件，里面记录了HR系统的登录日志，包括用户名、IP地址、登录时间。更关键的是，日志里出现了几次“登录失败：密码错误”的记录，错误密码字段直接写在了日志里。

我提交了报告，定级中危偏高，赏金几千块。修复方案是：日志Bucket不开放公网访问，审计人员通过VPN或内网访问。

案例三：子域名接管 + Bucket不存在 = 官方域名的钓鱼攻击

2026年7月，HITCON ZeroDay披露了一个案例：互动资通（TeamPlus）的两个子域名tp.teamplus.com.tw和download.teamplus.com.tw通过AWS CloudFront对外服务，但后端的S3 Bucket已经不存在了（返回NoSuchBucket错误）。

这意味着：任何人在AWS上创建一个同名的S3 Bucket，就能通过仍然活跃的CloudFront Distribution，以tp.teamplus.com.tw这个官方域名提供内容。攻击者可以上传伪造的安装程序或钓鱼登录页面，用户看到的域名是官方的，信任度极高。

这个漏洞的本质是“生命周期管理缺失”：Bucket被删除了，但DNS记录和CloudFront配置没有清理。攻击者利用这个空档，接管了官方的可信域名。

四、为什么这些问题在2026年依然普遍？

原因一：AI生成的代码，AI不知道云配置的风险。

2026年，大量开发者用AI生成应用代码。AI写出来的上传功能，通常会使用预签名URL或直接调用SDK。但AI不会告诉你“Bucket Policy应该怎么配”。开发者为了让代码跑通，去AWS控制台手动点了几个勾，把权限开大了。代码没问题，配置有问题。

原因二：“先让它跑起来”的心态。

很多团队在开发阶段为了调试方便，把Bucket权限开到最大。上线前忘了收回来。或者收回来了，但CI/CD流水线的权限没改，导致部署失败，于是又开回去了。

原因三：权限模型太复杂。

S3的权限模型有四层：ACL、Bucket Policy、IAM Policy、Block Public Access。四层叠加，互相覆盖，很难搞清楚最终生效的权限是什么。很多运维人员只检查了其中一层，就以为安全了。

原因四：对象存储的“信任惯性”。

因为amazonaws.com、aliyuncs.com、storage.googleapis.com这些域名在大多数安全设备里都是“可信”的，攻击者可以寄生在这些域名下进行钓鱼和C2通信，绕过网络层的信誉过滤。2026年4月，Mandiant披露的UNC6692组织就系统性地滥用AWS S3作为恶意载荷投放管道，用Teams消息投递钓鱼链接，受害者点击后从S3下载恶意文件。传统防火墙看到的是对amazonaws.com的HTTPS请求，不会拦截。

五、防御：一套可以直接落地的最小权限配置清单

如果你负责云存储安全，下面这份清单可以直接拿去用。我按优先级排序，从“必须做”到“应该做”。

必须做（不做就是裸奔）：

1. 开启Block Public Access。

AWS的S3在账户级别和Bucket级别都有Block Public Access开关。开启后，任何公开的ACL和Bucket Policy都会被忽略。这是最后一道防线。在AWS控制台中，进入S3 → 账户级Block Public Access，全部勾选。在阿里云OSS中，找到对应的“阻止公共访问”开关，同样开启。

2. Bucket Policy中的Principal永远不用"*"。

需要CDN读取静态资源？用CloudFront的Origin Access Control（OAC），让CloudFront的IAM角色成为唯一被允许的Principal。需要用户上传？用预签名URL或STS临时凭证，不要开公开写。

3. 关闭ListBucket权限。

除非你明确需要公开列举功能（比如公共数据集），否则关闭ListBucket。即使文件可以被公开读取，也不应该让攻击者知道有哪些文件存在。

应该做（做了能挡住大部分攻击）：

4. 为每个Bucket配置独立的IAM策略。

不要用一个“万能”的IAM用户管理所有Bucket。为每个业务场景创建独立的IAM角色，只授予必要的最小权限。例如：CI/CD角色只能写/build/目录下的文件，不能读/backup/目录。

5. 启用访问日志和异常监控。

开启S3的访问日志，记录所有请求的源IP、操作类型、目标对象。配置监控规则：当出现大量PutObject请求来自非常规IP时，触发告警。当出现PutObjectAcl操作时，立即告警。

6. 定期审计Bucket策略。

写一个脚本，遍历所有Bucket，检查Policy中是否存在Principal: "*"、是否开启了公开写、是否开放了ListBucket。每周跑一次，有变化就告警。

加分项（安全成熟度较高）：

7. 使用VPC终端节点限制访问来源。

阿里云的“VPC Policy + Bucket Policy”双重访问控制方案是一个很好的实践：VPC Policy在网络源端限制可访问的Bucket范围，Bucket Policy在存储目的端验证请求是否来自授权的VPC。即使Bucket Policy配置有误，VPC Policy也能拦住来自公网的请求。

8. 敏感数据加密和扫描。

对Bucket中的文件进行敏感数据扫描（身份证号、手机号、银行卡号、密钥模式）。如果发现敏感数据被存在了公开Bucket中，立即告警并自动将其转为私有。

六、写在最后

对象存储的Bucket Policy过度授权，是2026年云安全领域最普遍、最容易利用、也最容易被忽视的漏洞类型。它的危害不在于“数据被看到了”，而在于“你的域名和信誉变成了攻击者的武器”。

一个公开写的Bucket，让攻击者可以在你的官网上托管钓鱼页面。一个开放的ListBucket，让攻击者可以枚举你的全部内部资产。一个越界的策略权限，让攻击者可以接管整个存储账户。

下次你配置Bucket Policy时，先问自己三个问题：

• 这个Principal真的需要"*"吗？
• 这个Action真的需要PutObject吗？
• 如果这个Policy被攻击者利用了，最坏的结果是什么？

答案往往会让你把权限收得更紧一些。而在云安全的世界里，权限收紧从来不是坏事。

严正声明 本文所述技术仅用于合法授权的安全测试。所有案例均已脱敏处理，测试均在授权范围内进行。利用对象存储配置错误进行未授权访问或上传恶意文件属于违法行为，与作者无关。请遵守法律法规，定期审计云资源配置，守护数据安全。

免责声明：

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

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

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

本文转载自：昆仑AI安全实验室 www.klsec.com www.klsec.com《你的对象存储，正在替黑客养鱼：Bucket Policy过度授权+公开写，我把钓鱼页面传到了你公司官网上》