摘要：編注為什么標題是再次年，服務(wù)啟用新域名從換到之前有被跨域攻擊的危險。這些漏洞都已經(jīng)私下報告并及時修復了。在協(xié)議中有保護機制防止泄露的重定向，每個參數(shù)都簽發(fā)給對應(yīng)的。這是一個嚴重的問題，而且可以用來危害所有依賴用登陸功能的網(wǎng)站。

編注：為什么標題是“再次”？2013年，GitHub Page服務(wù)啟用新域名（從 page.github.com 換到 github.io）之前有被跨域攻擊的危險。Egor Homakov 寫了一篇博文證實。

這篇文章是關(guān)于我將5個危險性不高的漏洞組合起來，構(gòu)造一個簡單卻高危漏洞的故事。利用這個漏洞，我可以進入github上的用戶私有代碼倉庫。這些漏洞都已經(jīng)私下報告并及時修復了。

下面是我的郵件時間線：

幾天前，GitHub正式推出了一個賞金計劃，這個計劃對我來說是研究GitHub OAuth問題的絕佳動力。

我最先發(fā)現(xiàn)的是：

  
如果提供了的話，重定向URL的主機和端口必須嚴格匹配回調(diào)URL。重定向URL的路徑只能引用回調(diào)URL的一個子目錄。

然后，我嘗試用/../進行路徑遍歷，我成功了。

僅有第一個漏洞沒有什么價值。在OAuth2協(xié)議中有保護機制防止‘泄露的’重定向URI，每個code參數(shù)都簽發(fā)給對應(yīng)的‘redirect_uri’。要獲得訪問令牌必須提供你在認證流程中使用的準確的redirect_uri。

redirect_uri | string | 你的app中用戶認證后返回給用戶的URL。查看更多細節(jié)點擊 redirect_urls.

不幸的是，我決定研究一下這個保護機制有沒有被正確實現(xiàn)。

它確實是有缺陷：不管客戶端發(fā)送什么重定向uri來獲得令牌，提供商都會回復一個有效的訪問令牌。

要是沒有第一個漏洞，第二個漏洞也會要毫無價值。但是，它們卻組合成一個很強大的漏洞——攻擊者可以劫持一個簽發(fā)給泄露的重定向uri的授權(quán)令牌，然后把這個泄露的令牌用在真正的客戶端回調(diào)URl上，從而登陸受害者的賬戶。順便說下，這和我在VK.com發(fā)現(xiàn)的漏洞一樣。

這是一個嚴重的問題，而且可以用來危害所有依賴“用GitHub登陸”功能的網(wǎng)站。我打開了應(yīng)用頁面來查看哪些網(wǎng)站應(yīng)該檢查一下。這個部分引起了我的注意：

Gist、Education、Pages和Speakerdeck（注：前三個是Github的頻道站，后面是旗下站點）都是官方預(yù)先認可的OAuth客戶端。我沒有找到Pages和Education的client_id，Speakerdeck又超出了獎金范圍（我在那里發(fā)現(xiàn)了賬戶劫持，并獲得了$100）。那么，我們還是在Gist上尋找重定向泄露的頁面吧。

基本上，泄露的Referers有兩個向量：用戶點擊一個鏈接（需要交互）或用戶代理載入一些跨站資源，比如
我不能簡單的注入（img src=http://attackersite.com），因為這會替換成camo-proxy URL，這樣就不能把Referer頭傳遞到攻擊者的主機。為了能夠繞過Camo-s 過濾器，我用了一個小技巧：

你可以在開放重定向漏洞進展這篇文章中看到更多細節(jié)。

///host.com 被Ruby的URI庫解析成一個相對路徑URL，卻被Chrome和Firefox視為一個相對協(xié)議URL。下面是我們精心構(gòu)造的URL：

https://github.com/login/oauth/authorize?client_id=7e0a3cd836d3e544dbd9&redirect_uri=https%3A%2F%2Fgist.github.com%2Fauth%2Fgithub%2Fcallback/../../../homakov/8820324&response_type=code

當用戶載入這個URL時，Github會自動302 重定向自己。對應(yīng)地址：

https://gist.github.com/auth/github/callback/../../../homakov/8820324?code=CODE

但是用戶代理載入為：

https://gist.github.com/homakov/8820324?code=CODE

那么用戶代理會把發(fā)送請求的CODE泄露給我們的：

一旦我們獲得受害者的CODE，我們點擊 ：

https://gist.github.com/auth/github/callback?code=CODE

瞧，我們登陸進了受害者的賬號，然后我們可以進入私有的gists

我很想知道Gists是怎么把用戶會話和解碼的_gist_session存放在cookie（普通的Rails Base64編碼的cookie）里：

天啊，又一個OAuth的反面教材！客戶端絕不應(yīng)該暴露真正的訪問令牌給用戶代理。現(xiàn)在我們可以用這個github_token代表受害者賬戶來執(zhí)行API調(diào)用，并且不再需要Gist網(wǎng)站。我試著訪問私人代碼庫：

該死的，令牌的范圍顯然僅僅是Gists……

我的漏洞利用的最后部分。由于Gist是一個預(yù)先授權(quán)的客戶端，我猜想Github也自動認證了Gist客戶端請求的其他范圍。我果然對了

我們現(xiàn)在要做的只是把構(gòu)造的URL載入到受害者的瀏覽器：

https://github.com/login/oauth/authorize?client_id=7e0a3cd836d3e544dbd9&redirect_uri=https%3A%2F%2Fgist.github.com%2Fauth%2Fgithub%2Fcallback/../../../homakov/8820324&response_type=code&scope=repo,gists,user,delete_repo,notifications

用戶代理泄漏了受害者的CODE，攻擊者使用泄漏的CODE登陸進受害者的Gist賬戶，解碼_gist_session來盜取github_token等等。

私人代碼庫，讀寫權(quán)限等等——都秘密失竊，因為所用github_token是屬于Gist客戶端的。完美的犯罪，不是嗎？

$4000的獎勵真是太豐厚了。有趣的是，對他們來說購買我4~5個小時$400的咨詢服務(wù)，只需要$1600，這會更便宜。重要的是也要有眾包安全。最好是兩者都用:)

原文：How I hacked Github again
轉(zhuǎn)載自：伯樂在線 - 50infivedays