src过程中比较有意思的存储桶案例
前言
在挖某src的时候发现的一些比较有意思的案例。
案例一
发现点
在找资产的过程中发现了一个物流相关的小程序，发现一个可以上传的功能点。
进入添加货物添加，里面有个图片上传，是上传到桶里。
请求中隐去无关参数，关键参数是good_image，里面是一个key（图片的“路径”）。
然后再去获取这个对应的货物详情，发现返回的图片地址已经在后台给你签了名了。
直觉告诉我，这里有个问题，可以继续深入。
深入
既然后台会去给我传入的图片签名，那么可以测试的点来了，我如果输入的图片不是真实的key，直接是根目录呢？
再获取一下对应的详情，惊喜来了，根目录直接签名了。
直接访问已经能列出桶里面的文件了。
可以直接根据里面的key，再重复修改上面的good_image，让后台进行签名，来读取桶里的任意文件。
为了获取更多的文件，这里用到桶的两个参数。不同的厂商的可能有区别，这里是阿里的。
一个参数是max-keys，它定义了在一次请求内OSS返回文件和文件夹最大的数目，默认值是100，最大可以设成1000。当一个文件夹内有超过1000个文件时，可以利用另一个参数——marker。这个参数告诉OSS从指定的文件开始，按照字典序查其后面的文件。
直接看实例。
案例二
测试app的过程中，发现一个可以上传图片的功能点，同样是到桶里。
第一步会先去获取上传需要的参数，包含策略，accessid，签名，路径等。
然后进入上传，记得修改下后缀为静态文件，内容改成js代码直接过去。
然后访问，中危到手，好几伯块钱，是不是有手就行？
案例三
还是在测试app的过程中，发现一个可以上传图片的功能点，同样是到桶里，只是这次返回的东西有点意思，给了个STStoken。
这里讲下sts。
阿里云STS（Security Token Service）是阿里云提供的一种临时访问权限管理服务。RAM提供RAM用户和RAM角色两种身份。其中，RAM角色不具备永久身份凭证，而只能通过STS获取可以自定义时效和访问权限的临时身份凭证，即安全令牌（STS Token）。
是有时效性，ACL策略不严时，也是可以登录遍历桶的，至少会有个上传的权限。
这里直接用OSSBrowser访问，可以连上，又是好几伯块。
总结
这里只是关于桶的几个比较常见的玩法。常见的桶的玩法也就那么几种，要么遍历，要么劫持，要么密钥泄露，要么上传问题。
碰到的时候，一定要细细的测，再不济一个中危还是有的。
