万字长文学习云安全 STS Policy注入在漏洞挖掘中的妙用

原创

行之
行之

亿人安全

2026年10月13日 10:37
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

前言

我是行之，好久都没更新了，发一篇最近分析的文章吧。随着云原生架构的普及，针对凭据与身份边界的攻击正成为主流。正好近期得知朋友挖掘了几个严重漏洞，于是跟他学习了一下思路，然后研读了一下海外云安全文献，发现是通过针对 STS（Security Token Service，安全令牌服务）的攻击：借助文件名、接口入参等可控字段篡改 STS 令牌下发逻辑，通过 STS Policy 注入获取高权限临时令牌，由此触发高危云上漏洞。原本计划讲个议题的，但国内相关研究文章偏少，既然没什么文章基础，于是先写篇长文沉淀一下，本文是我的学习过程，会从 AK/SK、STS 的基础原理讲起，搭配本地靶场搭建与真实的实战案例，为国内安全同行、白帽子提供攻防思路参考。本文纯手写原创，全文共一万字，欢迎各位安全同行交流探讨，也在此感谢先知社区提供发布平台。

一、先从一个最熟悉的注入说起：SQL

首先讲解STS云注入，我们最好先回到所有人都见过的 SQL 注入。它的本质其实是用户输入的数据被当作数据库代码进行了执行，也就是输入流入侵到了控制流的一个过程。

后端这么去写：

SELECT \* FROM uploads WHERE owner = '{input}';

开发者心里，input只是一个字符串值。正常输入alice时，数据库看到：

SELECT \* FROM uploads WHERE owner = 'alice';

但当input变成alice' OR '1'='1，前面那个单引号先把原字符串闭合，后面的内容就进入了 SQL 语法，数据库最后看到的是一个永真条件：

SELECT \* FROM uploads WHERE owner = 'alice' OR '1'='1';

记住这条数据流，下面会把同一个解释器换成 JSON 和云授权：

用户输入 → 字符串拼接 → 某门语言的源码 → 解释器 → 改变了语义

这里关于SQL注入，笔者不再赘述。历史上的很多漏洞都是输入流入侵到了控制流的过程，例如

SSTI（模板注入）：输入进入 Freemarker、Velocity、Jinja2 的模板语法，${} 或 #{} 之间的内容被模板引擎当代码渲染，变成 RCE

Log4Shell（Log4j JNDI）：输入的字符串里带 ${jndi:...}，本该只是一行日志，却被 Log4j 当成查找指令触发 JNDI 加载，RCE。

所以只要我们能够找到输入流和控制流之间的关系，就可以更好的挖掘漏洞。

二、STS到底是个什么东西？

关于STS，很多人挖洞看到的通常是AK、SK、还有一个Token，比如长这个样子。

:\:examplebucket/exampledir/\*\" 那么 exampledir/../../target.txt 即使被接受，仍然只是一个以 exampledir/ 开头的 Key。它不会因此覆盖 Bucket 根部真正名为 target.txt 的对象。

简单来说就是无论你在客户端怎么传递，到了调用的时候其实还是会以字符串的形式进行传入，不能从输入流入侵到控制流。

哪些情况下会真的出现跨范围写入

这里自己学习了开发角度，就可以很容易明白如下这个案例

通过获取到的STS也是不能直接对OSS%20Browser拥有登录权限的

这里我们去看一下代码

在获取/api/v1/sts路由过来的fulPathFid参数后，发送给了AssumeRole(fullPathFid)

这里发现并没有对传递进来的内容做任何限制，而是传递到了下一层的provider.go

这里的第一个参数为bucket的值，是不可控的。第二个是fullpath的值，也就是文件名，此时文件名可控，所以最后的数据流转过程就是

main.go:77

读取%20文件名

↓

main.go:87

p.AssumeRole(fid)

↓

aliyun.go:24

生成%20Policy

↓

provider.go:38-41

fmt.Sprintf%20拼接%20fullPathFid

↓

aliyun.go:38

Policy%20放入%20AssumeRoleRequest

↓

aliyun.go:40

调用%20STS%20AssumeRole

↓

aliyun.go:45-55

返回临时%20STS%20凭证

还记得我们之前说过什么么，我们要找的是输入流可以入侵控制流的过程。我们来看这段代码

{

\"Version\":%20\"1\",

\"Statement\":%20[

{

\"Effect\":%20\"Allow\",

\"Action\":%20[

\"oss:GetObject\",

\"oss:PutObject\"

],

\"Resource\":%20[

\"acs:oss:\:\:%s/%s\"

]

}

]

}

此时我们知道了最后一个地方可以控制，那我们是不是可以注入写成

{

\"Version\":%20\"1\",

\"Statement\":%20[

{

\"Effect\":%20\"Allow\",

\"Action\":%20[

\"oss:GetObject\",

\"oss:PutObject\"

],

\"Resource\":%20[

\"acs:oss:\:\:存储桶的名字/x\"

],

\"Action\":%20[

\"oss:ListObjects\"

],

\"Resource\":%20[

\"acs:oss:\:\:存储桶的名字\"

]

}

]

}

这里很多人可能看不懂我在干什么，如果我把Payload拿出来应该就可以看得懂了。

这里的%20Payload%20会被放进原始%20Policy%20模板中第二个%20%s%20对应的位置。

原始代码是：

func%20aliyunVulnerablePolicy(bucket,%20fid%20string)%20string%20{

return%20fmt.Sprintf(

{\"Version\":\"1\",\"Statement\":[{\"Effect\":\"Allow\",\"Action\":[\"oss:GetObject\",\"oss:PutObject\"],\"Resource\":[\"acs:oss:\\*:\\*:%s/%s\"]}]},

bucket,%20fid)

}

假设

bucket%20=%20BUCKET

fid%20=%20x\"],\"Action\":[\"oss:ListObjects\"],\"Resource\":[\"acs:oss:\:\:\*

拼接后大致会变成：

{

\"Version\":%20\"1\",

\"Statement\":%20[

{

\"Effect\":%20\"Allow\",

\"Action\":%20[

\"oss:GetObject\",

\"oss:PutObject\"

],

\"Resource\":%20[

\"acs:oss:\:\:BUCKET/x\"

],

\"Action\":%20[

\"oss:ListObjects\"

],

\"Resource\":%20[

\"acs:oss:\:\:\*\"

]

}

]

}

这里我们依旧需要先理解几个基本概念。前面已经提到，Action%20代表允许执行的操作，Resource%20代表这些操作可以作用的资源。原本的代码只给%20Policy%20配置了：

\"Action\":%20[

\"oss:GetObject\",

\"oss:PutObject\"

]

拼接后的数据到底到了哪里？

因此，正常情况下，这份%20Policy只允许读取和上传对象，并没有%20oss:ListObjects%20权限。%20但现在，我把文件名参数当作%20Payload%20传入：%20x\"],\"Action\":[\"oss:ListObjects\"],\"Resource\":[\"acs:oss:\:\:\%20其中：%20x\"]%20用于闭合原来%20Resource%20数组中的字符串和数组；%20,\"Action\":[\"oss:ListObjects\"]%20用于追加新的%20Action%20字段；%20,\"Resource\":[\"acs:oss:\:\:\%20用于追加新的%20Resource%20字段，并把资源范围扩大到更大的范围。%20最后，原始模板后面剩余的：%20\"]}]}%20继续补全整个%20JSON%20结构。%20因此，问题并不是我们修改了%20Go%20源码中的%20Action，而是通过文件名参数注入，让原本只应当作为数据使用的%20fid%20参与了%20Policy%20JSON%20的生成。后端随后把这段拼接结果交给阿里云%20SDK，SDK%20再调用%20STS%20的%20AssumeRole%20接口申请临时凭证。

最终得到的Payload就变成了

?fid=x%22%5D%2C%22Action%22%3A%5B%22\%22%5D%2C%22Resource%22%3A%5B%22\

这里出现了重复键Action。绝大多数%20JSON%20解析器对重复键采用\"后者覆盖\"，于是这条%20Statement%20的Action最终是[\"\\",\"\"]，Resource是[bucket/\,%20\*]——一条%20Statement、Statement%20数还是%201，但权限已经被放大到\"任意动作、任意资源\"（受角色上限约束）。

所以%20Policy%20注入和%20SQL%20注入同构：边界字符从单引号换成双引号、方括号、花括号；解释器从%20SQL%20parser%20换成%20JSON%20parser%20+%20云端授权。修复思路也一样：数据保持数据，不让它参与语法生成。