一、Bucket 爆破
當不知道 Bucket 名稱的時候，可以通過爆破獲得 Bucket 名稱，這有些類似於目錄爆破，只不過目錄爆破一般通過狀態碼判斷，而這個通過頁面的內容判斷。
當對於阿里雲OSS 不存在有兩種返回情況，分別是
- InvalidBucketName：表示存儲桶的名稱不符合規範，屬於無效的存儲桶名稱
- NoSuchBucket：表示沒有這個存儲桶
當存儲桶存在時，則會返回以下兩種情況，
- 禁止列對象報錯
- 根目錄烈對象
這樣通過返回內容的不同，就可以進行 Bucket 名稱爆破了，知道 Bucket 名稱後，Key 的爆破也就很容易了。
參考鏈接：
https://zone.huoxian.cn/d/918-oss
二、Bucket Object 遍歷
如果設置了ListObject，這將會導致Bucket桶被遍歷。
三、任意文件上傳覆蓋
如果在配置存儲桶時，管理員錯誤的將存儲桶權限，配置爲可寫，這將會導致攻擊者可上傳任意文件到存儲桶中，或覆蓋已經存在的文件。
如果目標的對象存儲支持 html 解析，那就可以利用任意文件上傳進行 XSS 釣魚、掛暗鏈、掛黑頁、供應鏈投毒等操作。
需要注意的是，2018年8月13日之後開啓的Bucket，直接使用OSS訪問域名，從互聯網訪問OSS上的htm、 html、jsp、plg、htx 和stm類型文件時，都會被阿里雲直接強制下載。想要訪問自己的Buncket中的靜態頁面，則需要給這個Buncket配域名。
四、Bucket 接管
如果管理員通過域名解析並綁定了一個存儲桶，但是管理員將存儲桶刪除後，沒有將域名解析的CNAME刪除，這時會訪問舊域名就會出現報錯，NoSuchBucket。
這個時候可以登錄自己的阿里雲賬號，創建同樣的名稱即可成功接管了該存儲桶。
五、Bucket資源超範圍限定
在使用存儲桶進行對象讀取或寫入操作時，如果沒有合理的或者錯誤的在Policy中配置用戶允許訪問的資源路徑（resource），則會出現越權訪問，導致用戶數據被惡意上傳覆蓋或被其他用戶下載等安全問題。
在Web應用開發中，經常會發生此類問題。設想以下場景：在一個Web應用使用對象存儲來存儲用戶頭像，且通過前端直傳的方式將用戶上傳的頭像傳至存儲桶中，並希望在存儲桶/avatar/路徑中存儲桶用戶的頭像，由於後端開發時爲了方便而進行了不規範的存儲桶Policy配置，在生成用戶用以上傳頭像的臨時密鑰時直接將此臨時密鑰允許訪問的 resource 指定爲 qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/avatar/*路徑。
這樣以來，系統爲每個用戶所生成的用以上傳以及瀏覽頭像的臨時密鑰雖然不盡相同，但是這個臨時密鑰都擁有qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/avatar/*路徑中的所有資源的讀寫權限。
這一錯誤的配置導致了很多嚴重的安全問題，由於在此場景下，Web應用程序使用前端直傳的方式訪問存儲桶，因此後臺生成的臨時密鑰將會發送給前臺，任意用戶通過網絡抓包等手段獲取到的臨時憑據，可參見下圖流量中響應包內容。
在獲取了臨時密鑰之後，攻擊者憑藉此憑據讀寫qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/avatar/*路徑中的任意對象。
攻擊者可以通過此方式覆蓋目錄中其他用戶資源，見下圖：
上圖攻擊者通過test.txt文件覆蓋了16.png。當然，攻擊者也可以輕易的讀取此目錄中其他用戶的文件。
針對此問題的修復方式如下：可以通過每個用戶的用戶標識來爲每一個用戶設置一個獨用的路徑，例如可以在爲用戶生成臨時密鑰時，將policy中resource 指定爲 qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/avatar/<Username>/*來滿足規範要求；此外，resource 字段支持以數組的形式傳入多個值。因此，也可以顯式指定多個 resource 值來完全限定用戶有權限訪問的最終資源路徑。
參考鏈接：https://mp.weixin.qq.com/s/ncWGrMsIAvh9HEK1QC5IGQ