tencent cloud

对象存储

动态与公告
产品动态
产品公告
产品简介
产品概述
功能概览
应用场景
产品优势
基本概念
地域和访问域名
规格与限制
产品计费
计费概述
计费方式
计费项
免费额度
计费示例
查看和下载账单
欠费说明
常见问题
快速入门
控制台快速入门
COSBrowser 快速入门
用户指南
创建请求
存储桶
对象
数据管理
批量处理
全球加速
监控与告警
运维中心
数据处理
内容审核
智能工具箱
数据工作流
应用集成
工具指南
工具概览
环境安装与配置
COSBrowser 工具
COSCLI 工具
COSCMD 工具
COS Migration 工具
FTP Server 工具
Hadoop 工具
COSDistCp 工具
HDFS TO COS 工具
GooseFS-Lite 工具
在线辅助工具
自助诊断工具
实践教程
概览
访问控制与权限管理
性能优化
使用 AWS S3 SDK 访问 COS
数据容灾备份
域名管理实践
图片处理实践
COS 音视频播放器实践
工作流实践
数据直传
内容审核实践
数据安全
数据校验
大数据实践
COS 成本优化解决方案
在第三方应用中使用 COS
迁移指南
本地数据迁移至 COS
第三方云存储数据迁移至 COS
以 URL 作为源地址的数据迁移至 COS
COS 之间数据迁移
Hadoop 文件系统与 COS 之间的数据迁移
数据湖存储
云原生数据湖
元数据加速
数据加速器 GooseFS
数据处理
数据处理概述
图片处理
媒体处理
内容审核
文件处理
文档处理
故障处理
获取 RequestId 操作指引
通过外网上传文件至 COS 缓慢
访问 COS 时返回403错误码
资源访问异常
POST Object 常见异常
API 文档
简介
公共请求头部
公共响应头部
错误码
请求签名
操作列表
Service 接口
Bucket 接口
Object 接口
批量处理接口
数据处理接口
任务与工作流
内容审核接口
云查毒接口
SDK 文档
SDK 概览
准备工作
Android SDK
C SDK
C++ SDK
.NET(C#) SDK
Flutter SDK
Go SDK
iOS SDK
Java SDK
JavaScript SDK
Node.js SDK
PHP SDK
Python SDK
React Native SDK
小程序 SDK
错误码
鸿蒙(Harmony) SDK
终端 SDK 质量优化
安全与合规
数据容灾
数据安全
访问管理
常见问题
热门问题
一般性问题
计费计量问题
域名合规问题
存储桶配置问题
域名和 CDN 问题
文件操作问题
日志监控问题
权限管理问题
数据处理问题
数据安全问题
预签名 URL 问题
SDK 类问题
工具类问题
API 类问题
服务协议
Service Level Agreement
隐私政策
数据处理和安全协议
联系我们
词汇表
文档对象存储实践教程访问控制与权限管理用于前端直传 COS 的临时密钥安全指引

用于前端直传 COS 的临时密钥安全指引

PDF
聚焦模式
字号
最后更新时间: 2024-01-06 10:47:50

简介

在移动应用和 Web 应用中,您可以通过 iOS/Android/JavaScript SDK 在前端直接向对象存储(Cloud Object Storage,COS)发起请求,此时数据的上传和下载可以不经过您的后端服务器,既节约了您后端服务器的带宽和负载,还可以充分利用 COS 的带宽和全球加速等能力,提升您的应用体验。
在实际应用中,您需要使用临时密钥作为前端的 COS 请求签名,以防止永久密钥的泄漏及越权访问等问题。然而,即便是使用临时密钥,如果您在生成临时密钥时指定了过大的权限或路径,那么同样有可能发生越权访问等问题,将对您的应用带来一定的风险,本文重点介绍了部分风险案例,以及您应当遵守的安全规范,以便让您的应用能够安全的使用 COS。

前提条件

本文假定您已经充分理解临时密钥的相关概念,能够生成及使用临时密钥来请求 COS。有关临时密钥的生成及使用指引,请参见 临时密钥生成及使用指引 文档。
注意
使用临时密钥授权访问时,请务必根据业务需要,按照最小权限原则进行授权。如果您直接授予所有资源(resource:*),或者所有操作(action:*)权限,则存在由于权限范围过大导致的数据安全风险。

反面案例与安全规范

反面案例一:资源(resource)超范围限定

应用 A 在注册用户上传头像中使用到了 COS,每个注册用户的头像拥有固定的对象键app/avatar/<Username>.jpg,同时还会包含头像的不同尺寸,对应的对象键分别为app/avatar/<Username>_m.jpgapp/avatar/<Username>_s.jpg,后端为了方便使用,在生成临时密钥时直接将 resource 指定为qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/app/avatar/*,此时恶意用户通过网络抓包等手段获取到生成的临时密钥后,可以覆盖上传任何用户的头像,产生越权访问,用户的合法头像数据被覆盖导致丢失。

安全规范

resource 代表临时密钥所允许访问的资源路径,此时需要充分考虑该路径所覆盖的最终用户,原则上 resource 所指定的资源要求仅能被单一用户所使用。此案例中指定的qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/app/avatar/*显然会覆盖所有用户,因此存在安全漏洞。
在该案例中,可以考虑将用户的头像路径修改为app/avatar/<Username>/<size>.jpg,此时可以将 resource 指定为 qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/app/avatar/<Username>/*来满足规范要求;此外,resource 字段支持以数组的形式传入多个值。因此,您也可以显式指定多个 resource 值来完全限定用户有权限访问的最终资源路径,例如:
"resource": [
"qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/app/avatar/<Username>.jpg",
"qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/app/avatar/<Username>_m.jpg",
"qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/app/avatar/<Username>_s.jpg"
]

反面案例二:操作(action)超范围限定

应用 B 提供一个公共的照片墙功能,所有照片均存放置在app/photos/*下面,客户端同时需要列出对象(GET Bucket)和下载对象(GET Object)操作,后端为了方便使用,在生成临时密钥时直接将 action 指定为了name/cos:*,此时恶意用户通过网络抓包等手段获取到生成的临时密钥后,可以对该资源路径下的任何对象执行所有对象操作(例如上传和删除等操作),产生越权访问,导致数据丢失,影响线上业务。

安全规范

action 代表临时密钥所允许请求的操作,原则上不允许使用name/cos:*等允许所有操作的临时密钥下发至前端,必须明确列出所有需要用到的操作,同时如果各操作所需的资源路径不同,则需要操作资源路径单独匹配,而不应合并处理。
在该案例中,应当使用"action": [ "name/cos:GetBucket", "name/cos:GetObject" ]指明具体的操作。授权操作指引请参见 COS API 授权策略使用指引

反面案例三:资源与操作超范围限定

应用 C 提供一个管理工具,允许用户列出并下载所有人的文件(app/files/*),但只能上传和删除个人目录下的文件(app/files/<Username>/*),后端为了方便使用,在生成临时密钥时将2种权限,共4种操作(action)混合在一起。2种权限对应的资源路径也混合在一起,此时的临时密钥将具备资源路径中指定的更大权限,即用户可以列出、下载、上传和删除所有人的文件,恶意用户可以据此篡改或删除他人的文件,产生越权访问,用户的合法数据将暴露在风险之中。

安全规范

对于多个 action 与 resource 的组合,不应简单的将它们分别合并,而应当通过多个 statement 的形式组合在一起,避免简单的分别合并导致权限扩大化。
在该案例中,应当使用
"statement": [
{
"effect": "allow",
"action": [
"name/cos:GetBucket",
"name/cos:GetObject"
],
"resource": "qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/app/files/*"
},
{
"effect": "allow",
"action": [
"name/cos:PutObject",
"name/cos:DeleteObject"
],
"resource": "qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/app/files/<Username>/*"
}
]

反面案例四:越权获取临时密钥

应用 D 提供一个论坛应用,论坛的帖子附件保存在 COS 上,该论坛应用分为不同的用户级别,只有发帖数达到一定阈值的活跃用户才能看到某个版面内的帖子和附件,对于一些公共版面,所有用户均可以查看其中的帖子和附件。 在使用 COS 时,后端生成临时密钥的接口会根据前端传入的版面 ID ,生成允许下载对应版面附件的临时密钥。但在实现过程中,后端没有判断具体请求的用户是否有权限访问指定的版面 ID,导致任何人均可请求该接口获取可访问私密版面附件的临时密钥,产生越权访问,需要被限制访问的资源未能被有效限制,导致数据意外泄漏。

安全规范

对于获取临时密钥的接口,除了要保证获取到的临时密钥本身的权限在预期范围中,还应判断实际的业务场景,即正确的权限是否被正确的用户所请求,避免低权限用户拿到高权限的临时密钥。
在本案例中,后端接口还应该判断当前请求用户是否具备访问特定版面的权限,如无权访问则不允许返回临时密钥。

总结

以上几个案例说明了在预期外扩大临时密钥的权限可能导致的安全风险。由于前端直传 COS 时,恶意用户比较容易获取到临时密钥内容,因此该场景相对于通过后端访问 COS 来说,需要开发者们更加注重权限的控制。
本文提到的安全规范即最小权限原则,在实际应用中,根据 action 和 resource 可以枚举出所有可能的权限,例如3种 action 和2个 resource,可以计算出3 x 2=6个被允许访问的资源和对应的操作,您可以据此评估每一种情况是否符合预期,如超出预期权限范围,则应当考虑通过枚举多个 statement 的方式拆分权限。
此外,用于生成临时密钥的接口本身也要充分考虑身份认证和鉴权处理,只有获取临时密钥的行为是安全的,这样得到的临时密钥才能确保真正安全。安全链条上,不能有任何一处疏漏!

帮助和支持

本页内容是否解决了您的问题?

填写满意度调查问卷,共创更好文档体验。

文档反馈