怎么綜合利用Self-XSS和OAuth錯誤配置實現Stored-XSS

怎么綜合利用Self-XSS和OAuth錯誤配置實現Stored-XSS，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

下面是對Self-XSS和OAuth錯誤配置兩個低危漏洞的組合利用，形成Stored XSS的一個梳理過程，僅當思路拓展。由于測試保密原因，目標測試網站用redacted.com來代替描述。

漏洞發現

在HackerOne平臺參與的一個邀請測試項目中，我發現了一個AngularJS 客戶端模板的Self XSS漏洞和一個OAuth實現的錯誤配置漏洞，單獨來看，這兩個漏洞都屬于低風險漏洞，形成不了嚴重的隱患影響。但經過我對它們的組合利用，就可以形成一個完美的Stored XSS ！

目標測試網站redacted.com，它主要提供文件存儲服務，有點像Google Drive 和 DropBox的樣子，用戶通過注冊使用這個平臺，可以實現文件的上傳、下載和分享。

存在XSS的地方位于待上傳文件的文件名處，如果把待上傳文件的文件名改為{{constructor.constructor(‘alert(1)’)()}}.jpg這種樣式，就會在上傳文件管理面板中導致XSS，啊，可它卻是一個Self XSS。

后經測試，有一種簡單的方法可以讓這個Self XSS轉變為Stored XSS，那就是向其它用戶共享文件的上傳鏈接，當文件被以相同的文件名從上傳面板中導入時，就會導致Stored XSS。但在這里，我還要展示另外一種轉變為Stored XSS的有趣方式。

OAuth錯誤配置

在設置菜單中，我發現了一個可以從DropBox導入文件的功能，使用這個功能，用戶需要在OAuth機制下，把redacted.com的應用和Dropbox賬戶相關聯。這里，來簡單地介紹一下redacted.com應用的大致OAuth機制：

1、首先，用戶點擊Dropbox關聯按鈕，然后會產生一個GET發起請求：

https://dropbox.com/oauth3/authorize?client_id=***********&response_type=code&state=****************&redirect_uri=https%3A%2F%2Fwww.redacted.com%2Faccount%2Fsettings%2Fdropbox-callback

2、接下來，當前redacted.com應用的用戶會跳轉到Dropbox，進行一個相應的Dropbox登錄和允許按鈕點擊：

3、點擊允許Allow后，會產生一個發往redacted.com且包含 state 參數和驗證碼auth_code的GET請求，如下紅框所示：

4、redacted.com后端接收并處理這個GET請求后，用戶的Dropbox賬戶就能與當前redacted.com應用同步了，所有Dropbox相關的文檔都可導入到redacted.com應用中來；

我在測試這個OAuth機制的過程中，目的在于發現能否把我的Dropbox賬戶關聯到其它redacted.com應用上，但卻沒什么發現。

其中涉及的redirect_uri是白名單化的，state參數方式也都合理，auth_code不能兩次復用，等等，而且我還測試了state參數，也即redacted.com應用是否用當前用戶會話對其進行驗證，結果都沒什么問題。

所以，基于以上這些測試來看，我肯定不能用來自Dropbox的鏈接 https://www.redacted.com/account/settings/dropbox-callback?state=********code=**********，去關聯其他的redacted.com用戶賬戶。

出于好奇，我刪除了https://www.redacted.com/account/settings/dropbox-callback?state=********code=**********鏈接中的state參數，變成了https://www.redacted.com/account/settings/dropbox-callback?code=**********，并把它放到了redacted.com的其他用戶賬戶中，驚喜的是，之后我的Dropbox賬戶就和其他用戶賬戶關聯起來了。

也就是說，只需要用一個GET請求，我就可以把我的Dropbox賬戶和其他任何人的redacted.com賬戶相關聯。在這里，你可能會有疑問，我不用Dropbox賬戶來登錄redacted.com應用，這就不能發生賬號劫持了。但如前所述，在待上傳文件的文件名處存在XSS，那么我們就可以考慮來充分利用利用它。

漏洞利用場景

1、在Dropbox中，上傳一個名為{{constructor.constructor(‘alert(1)’)()}}.jpg的惡意文件，這是Dropbox允許的；

2、把Dropbox驗證redacted.com應用且不包含state參數的最終OAuth鏈接https://www.redacted.com/account/settings/dropbox-callback?code=**********，發送給目標受害者；

3、當受害者的redacted.com應用和我們的Dropbox賬戶關聯后，一旦他向redacted.com應用中導入那個惡意文件時，我們文件名方式的XSS payload就會執行。

這里的問題在于，盡管redacted.com后端用當前的session會話對用戶的state參數進行了驗證，但卻沒驗證它的存在性。redacted.com后端的驗證邏輯大概是這樣的：

if(isset($_GET['state'])){
    if($_GET['state'] != current_user_state)
        ACCESS DENIED
        exit()
}
ACCESS GRANTED

所以，利用低危的OAuth錯誤配置和Self XSS，最終實現了具有危害性的Stored XSS。

看完上述內容，你們掌握怎么綜合利用Self-XSS和OAuth錯誤配置實現Stored-XSS的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！