分享幾個比較有意思的儲存桶測試案例
前言
給大家分享一下在挖某src的時候發(fā)現(xiàn)的一些比較有意思的案例，廢話不多說，直接上操作。
案例一
發(fā)現(xiàn)點
在找資產(chǎn)的過程中找到了一個業(yè)務，發(fā)現(xiàn)一個可以上傳的功能點。有個添加貨物功能，里面有個圖片上傳，是上傳到桶里的。
請求中隱去無關參數(shù)，關鍵參數(shù)是good_image，里面是一個key（圖片的“路徑”）。
然后再去獲取這個對應的貨物詳情，發(fā)現(xiàn)返回的圖片地址已經(jīng)在后臺給你簽了名了。
直覺告訴我，這里有個問題，可以繼續(xù)深入。
深入
既然后臺會去給我傳入的圖片簽名，那么可以測試的點來了，我如果輸入的圖片不是真實的key，直接是根目錄呢？
再獲取一下對應的詳情，驚喜來了，根目錄直接簽名了。
直接訪問已經(jīng)能列出桶里面的文件了。
可以直接根據(jù)里面的key，再重復修改上面的good_image，讓后臺進行簽名，來讀取桶里的任意文件。
為了獲取更多的文件，這里用到桶的兩個參數(shù)。不同的廠商的可能有區(qū)別，這里是阿里的。
一個參數(shù)是max-keys，它定義了在一次請求內(nèi)OSS返回文件和文件夾最大的數(shù)目，默認值是100，最大可以設成1000。當一個文件夾內(nèi)有超過1000個文件時，可以利用另一個參數(shù)——marker。這個參數(shù)告訴OSS從指定的文件開始，按照字典序查其后面的文件。
直接看實例。
案例二
測試app的過程中，發(fā)現(xiàn)一個可以上傳圖片的功能點，同樣是到桶里。 第一步會先去獲取上傳需要的參數(shù)，包含策略，accessid，簽名，路徑等。
然后進入上傳，記得修改下后綴為靜態(tài)文件，內(nèi)容改成js代碼直接過去。
然后訪問，中危到手，好幾百塊錢，是不是有手就行？
案例三
還是在測試app的過程中，發(fā)現(xiàn)一個可以上傳圖片的功能點，同樣是到桶里，只是這次返回的東西有點意思，給了個STStoken。
這里講下sts。
阿里云STS（Security Token Service）是阿里云提供的一種臨時訪問權限管理服務。RAM提供RAM用戶和RAM角色兩種身份。其中，RAM角色不具備永久身份憑證，而只能通過STS獲取可以自定義時效和訪問權限的臨時身份憑證，即安全令牌（STS Token）。
是有時效性，ACL策略不嚴時，也是可以登錄遍歷桶的，至少會有個上傳的權限。
這里直接用OSSBrowser訪問，可以連上，又是好幾伯塊。
總結
這里只是關于桶的幾個比較常見的玩法。常見的桶的玩法也就那么幾種，要么遍歷，要么劫持，要么密鑰泄露，要么上傳問題。 碰到的時候，一定要細細的測，再不濟一個中危還是有的。