技术解析

请教阿里云 OSS 直传安全性问题
0
2021-06-03 22:31:23
idczone

项目设计的时候,直传 OSS 没有完全按照阿里云给的方案,回调服务端这种模式。而是使用了如下模式:

  1. 前端请求后端获取临时授权 TO美国服务器KEN
  2. 前端将文件上传到阿里云 OSS,得到文件 URL
  3. 前端将文件 URL 传给后端。

目前后端只做了简单的效验,就是效验前端给的文件 URL 的域名是否指定的域名。

担心:这个方案是否有很大漏洞?比如:给到后端的文件 URL 给换成了非法地址。

请问有更好一点的效验 URL 合法性的做法吗?


token 可以直接签上路径或者文件名的

前面加个 minio 代理

sts 有效期内可以多次使用,可能会有问题:
先上传一个人畜无害的内容,提交后,哪怕你后端有校验 URL,在 sts 过期之前我依然可以再次上传覆盖,可能导致一个,内容合规检查之后被篡改。

是否有漏洞用一个简单的检验方法。如果我通过抓包知道了你上述的 1 、2 、3 逻辑,是否可以写个脚本来蹭你 oss 存点儿自己的东西?从目前的描述看,我感觉是可以的。
加签并不能杜绝上面的问题,只是加大了破解的难度。
所以不知道请求是否有用户态?有的话加上用户 token,请求加上签名,后端再针对用户加上存储配额的管理,一定程度上能防范上述的问题。

不知道这个临时 token 有效期多久,但是 token 这样传很容易被人拿去再次利用;
另外就是如你所说的,url 容易被篡改成恶意文件,可以考虑做签名校验,防止被篡改

签名时指定上传到特定目录,如 /tmp/random_xxxxx (每用户每次上传唯一)。
上传后提交相对路径,服务端检测文件后直接移走,数据看保存移动后的文件名 /路径。
定时脚本清理 /tmp 目录即可,不过依然建议使用 callback,对上传的文件更可控,及时清理非法的文件。
另,存储最好是开为私有,然后加签名访问,避免盗链。

这个问题,采用阿里云给的方案依然会面临你说的这个情况啊,你们是怎么做的?开启禁止覆盖文件?

有用户登录的,存储空间问题不大,目前还不考虑限制用户,有效期内可使用,是没问题的,其他 APP 也是这样做的,因为这个临时 TOKEN,你自己的也只有你自己知道,用 APP 上次和你用脚本上次,最终结果是一样的,服务端效验好文件的合法性就好了。

没有办法和途径获取到其他用户的临时 TOKEN 吧?如果有的话,那也是系统有其他漏洞造成的吧?而不是说这个授权模式存在问题。

上传是到了阿里的 OSS,不用我自己保管了,盗链也不用担心,阿里直接有防盗链功能。

url 合法性是指?
如果是标准 s3 协议,后端不给前端 token,直接给预签名的地址,这样前端能操作的入口,都需要申请
例如上传,就先申请一个预签名的上传接口和一个操作 id,完成后告诉后端,这个操作已完成
后端根据这个操作 id,获取对应的文件所在的 bucket,id 等字段

url 给到后端时, 后端拿着路径去 oss 检查一下文件是否合理存在

诶,这个方案安全性很高咦,请问阿里云支持这个方案吗?有没有相关文档地址啊,感谢!

这个也可以,多了一步效验,感觉这样安全很多。

你引用的 sdk 应该有 generatePresignedUrl 的方法

https://help.aliyun.com/document_detail/99373.html?spm=5176.8465980.0.0.3ca61450utq3Qc 官方文档的地址,你看看

URL 只存相对路径就好了吧。返回的时候自动加上域名。

好的,谢谢

这种做法也行,和我那个效验指定域名的行为差不多,我就是想知道,他后面一部分相对路径的 URL,有没有可能构造出一个有攻击漏洞的 URL ?

比如,我们正常希望前端给我们传一个这样的 URL 资源地址:/110/images/a.png ,结果他构造了这样一个地址:/110/images/a.png#disabledFeatures=[]&enabledFeatures=%20[]&indicatorsFile=data:application/javascript,alert(1)
我们应该如何去防范他?

我记着腾讯云 cos 是可以对 content-length 头,或者文件 md5 进行签名。

数据地带为您的网站提供全球顶级IDC资源
在线咨询
专属客服