请问下 OSS 的上传安全性大家是怎么保证的啊

[intermole]

oss 如果按照官网的最佳实践，是直接前端 js 直传 oss 的，那上传过程就完全绕开了自己的服务器，我都没办法知道图片是哪个用户上传的……那如果黑客拿到 STS 令牌以后，调用脚本疯狂上传，不是很快就把 oss 的容量耗光了啊，请问在直传这种场景里，有没有办法针对用户进行上传流量限制的？

[b821025551b]

@U2Fsd #18 蛤？

[walkersz]

sts 要是能限制上传个数就好了

[opengps]

我本身就是做阿里云上云支持业务的，这种做法并没有什么不可取，反而更容易对传统项目做改造：不需要前端工作，后端少量文件做 oss 的 sdk 对接即可。
@U2Fsd 这是网络 io 为主，硬盘 io 低是虚拟化系统的通病，不是因为这个做法的问题，更何况，作为用户买了服务，怎么用法已经不归阿里云的负责范围了
@intermole 你说的情况已经需要做 SLB 负载均衡了，有了负载均衡从后端看跟单台没区别，不至于出现你说的瓶颈导致项目扩容受阻

[huijiewei]

后台获取签名给前端就是了

[U2Fsd]

@intermole #20

[JavaScript 客户端签名直传] 时，AccessKeyID 和 AcessKeySecret 会暴露。

如果要直传就要用 [服务端签名直传] 。

[U2Fsd]

@opengps #23

文件上传到 ECS 的速度，和上传到 OSS 的速度一样快吗？

[newtype0092]

后台生成令牌给前端，前端拿着令牌去上传。
你生成 STS 令牌是可以控制上传参数的，本次上传的文件允许的前缀或文件名，文件大小，是否可以覆盖都是你设置好的啊，黑客拿到令牌也只能按这个规则上传的。

[iyaozhen]

还有个直传 OSS 的好处可以上传加速，不然用户到自己服务器跨地域比较慢

[mymx2]

既然 oss 没办法做次数限制。那就设置令牌过期时间短一点。不做长时间的令牌，从服务器获取令牌的时候做次数限制。

另外从 web 直传还要指定不同类型 Content-Type，用户可以直传 html。Content-Type 做了指定，用户想直传还要获取不同类型的令牌。

web 端直传就是为了方便，安全性肯定不如服务端上传。

[qq73666]

看官方文档啊,有鉴权的

[arthas2234]

OSS 我记得是可以绑定域名的

[raopeize]

@mymx2 其实大部分做转发上传更不安全

[akira]

与其担心容量，还不如担心下黑客刷下载刷到你们破产

[mangoDB]

你可以把生成 session token 的有效时间设置尽可能短一点。即使被别有用心的人拿到，也不会产生太大的影响，OSS 的后端肯定是有流控的，短时间内应该不会“刷爆“。

[stanzhou]

@akira 恶意刷流量这个是怎么解决的

[mailmac]

我来喷一喷，阿里云 oss 的 STS 吧， 好用个 P， 一大堆没有完成的功能，支持的包，和文档都写的稀烂。 各种功能不支持。
感觉就是一些管理功能不开放，恨不能大家，把什么东西都往里面塞，多下载点东西它才能赚流量的钱。
还写的最佳实践。。。 臭不要脸。

[inktiger]

这几天也在使用 oss，今天问了阿里技术人员，争对一系列大致做了这么几种流程处理方案

争对这个要利用好两个东西，一个是回调，一个是 policy 参数

我现在做的方法是让他一次签名只能上传一个文件，通过在 policy 里面设置 content-length-range(文件大小限制)和 key(文件路径)，来控制用户的上传策略，如果严格一点还可以设置必须让用户上传的文件类型

例如：
content-length-range=524288 字节
key=/user/logo/3f7a68dbfa984a189f80612343064f32.png

在前端，用户也只能设置相同参数才能上传，不管黑客是怎么拿到的这个签名，他始终得保证，文件大小在 512kb 内，以及上传到 oss 最终的名称会是 /user/logo/3f7a68dbfa984a189f80612343064f32.png

再者，为了防止黑客调用脚本疯狂上传，我觉得这个并不应该把他算在 oss 这边，首先，黑客要拿到签名，你为什么会给他呢？肯定是他是你网站的用户，在你程序没有 bug 的情况下，他是通过正常流程获取到的，争对你自己网站上的用户，你可以给他规定权限，比如这个用户他只有 1 个 G 的空间，在上传文件前其实我们能知道文件大小的，那么我们可以在获取签名的时候减去他的可上传空间，满足条件才给他下发签名

至于如何做知道是哪个用户上传的，我觉得你可以在文件名上做手脚，比如用户 id 为 1，获取签名得到文件名值 3f7a68dbfa984a189f80612343064f32.png ，那么在下发的时候是否可以以文件名为 key，id 为 value 临时储存在 redis 来做一个关联呢，这样上传成功之后，通过 oss 的回调里的文件名参数，我们就能找到用户，这样肯定能判断具体是哪个用户上传的，如果还不能判断，那说明至少是程序这边出现了权限上的 bug，问题还是我们自己

还有一个签名可以做一些小处理，比如一个签名可以规定 3 秒钟有效，其实这个也无所谓了，就算是 30 分钟过期，黑客拿着这个，他也只能局限在我们策略内的文件大小和文件名及特定格式操作，就算在这个签名内他连续上传，也只会是覆盖那同一张图片，所以造不成什么威胁，他就算在 30 分钟内上传 100 万张图片，也只玩的是那一张图片，512kb，一直做的覆盖操作，关键是，他请求的是阿里的服务器，oss 内 /外网流入流量是免费的我们更不需担心

所以只要我们自己把关好自己系统这边的逻辑，直传这种方式我觉得是使用 oss 最好的方式，毕竟我实在不喜欢图片上传还要走一遍自己服务器

[inktiger]

另外忘说了，还有一个东西，用 callback 回调参数来做用户安全验证也是可以的，把需要 oss 回调返给你的东西全部放在 callbackBody 这个字段里
如：
filename=${object}&size=${size}&mimeType=${mimeType}&height=${imageInfo.height}&width=${imageInfo.width}&userId=5&companyId=100
这样，上传成功了的话，oss 会回调你的接口，把上面的数据像文件名用户 id，公司 id，图片大小等各种结果返回给你

另外，切记，callback 这个参数需要把他放在 policy 里进行生成签名，不然，如果有恶意操作的用户在前端请求的时候，可以修改 callback 的值的