網絡安全不容忽視，不過這些看起來的黑客其實也不是很神祕，這都是實際開發中會遇到的問題哦~
另外特別注意，他找的這個bug，一個下午就賺了4000美刀，是不是很羨慕呢~你還在想着在淘寶再種一次紅包就太弱了~
|
Egor Homakov（Twitter: @homakov 個人網站: EgorHomakov.com）是一個Web安全的佈道士，他這兩天把github給黑了，並給github報了5個安全方面的bug，他在他的這篇blog——《How I hacked Github again》（牆）說明了這5個安全bug以及他把github黑掉的思路。Egor的這篇文章講得比較簡單，很多地方一筆帶過，所以，我在這裏用我的語言給大家闡述一下黑掉Github的思路以及原文中所提到的那5個bug。希望這篇文章能讓從事Web開發的同學們警惕。關於Web開發中的安全事項，大家可以看看這篇文章《Web開發中的你需要了解的東西》 OAuth簡介首先，這個故事要從Github OAuth講起。所以，我們需要先知道什麼是OAuth。 所謂OAuth就是說，第三方的應用可以通過你的授權而不用知道你的帳號密碼能夠訪問你在某網站的你自己的數據或功能。像Google, Facebook, Twitter等網站都提供了OAuth服務，提供OAuth服務的網站一般都有很多開放的API，第三方應用會調用這些API來開發他們的應用以讓用戶 擁有更多的功能，但是，當用戶在使用這些第三方應用的時候，這些第三方的應用會來訪問用戶的帳戶內的功能和數據，所以，當第三應用要幹這些事的時候，我們 不能讓第三方應用彈出一個對話框來問用戶要他的帳號密碼，不然第三方的應用就把用戶的密碼給獲取了，所以，OAuth協議會跳轉到一個頁面，讓用戶授權給 這個第三方應用以某些權限，然後，這個權限授權的記錄保存在Google/Facebook/Twitter上，並向第三方應用返回一個授權token， 於是第三方的應用通過這個token來操作某用戶帳號的功能和數據時，就暢通無阻了。下圖簡單地說明了Twitter的OAuth的授權過程。
從上面的流程圖中，我們可以看OAuth不管是1.0還是2.0版本都是一個比較複雜的協議，所以，在Server端要把OAuth實現對並不是一些容易事，其總是或多或少會有些小錯誤。Egor就找到了幾個Github的OAuth的實現的問題。 OAuth的Callback還需要注意的是，因爲OAuth是需要跳到主站的網頁上去讓用戶授權，當用戶授權完後，需要跳轉回原網頁，所以，一般來說，OAuth授權頁都會帶 一個 redirect_url的參數，用於指定跳轉回原來的網頁。Github使用的這個跳轉參數是redirect_uri參數。一般來 說，redirect_uri這個參數需要在服務器端進行驗證。 你想一下，如果有人可以控制這個redirect_uri這個參數，那麼，你就可以讓其跳轉到別的網頁上（可能會是個有惡意的網頁）。如果你覺得跳 轉到別的網頁上也無所謂，那麼你就錯了。別忘了，當你對這個第三方的應用授權通過後，服務方會給第三方應用返回一個授權token，這個token會被加 到那個redirect_uri參數後面然後跳轉回去，如果這個redirect_uri被別有用心的人改一個惡意的網址後，這個token也就被轉過去 了，於是授權token也就被泄漏過去了。 知道了這一切，我們就可以理解Egor提的那5個bug是什麼意思了。 第一個Bug — 沒有檢查重定向URL中的/../首先，我們通過Github的 redirect_uri 的說明文檔我們可以看到這樣的說明：
而Github對於redirect_uri做了限制，要求只能跳回到 https://gist.github.com/auth/github/callback/，也就是說，域名是gist.github.com，目錄 是/auth/github/callback/，服務器端做了這個限制，看似很安全了。 但是，Egor發現，Github的服務器端並沒有驗證.. /../../這樣的情況。 於是，Egor相當於構造了一個下面這樣的Redirect URL：
於是上面的URL就相當於：
你可以看到，認證後的跳轉網頁轉到了別的地方去（並非是github限制的地方）——我們知道Github的gist雖然是給你分享代碼片段的，但是也可以用來定製自己的東西的（比如markdown），這個gist的網頁當然是被Egor所控制的。 第二個BUG — 沒有校驗token第一個bug其實並沒有什麼，如果服務器端要校驗一下token是否和之前生成的token的redirect_uri一模一樣，只要服務器做了這個驗證，第一個bug完全沒有什麼用處，但是，github的服務端並沒有驗證。 這就是第二個bug，於是第一個和第二個bug組合起來成了一個相當有威力的安全漏洞。 也就是說，token的生成要考慮redirect_uri，這樣，當URL跳轉的時候，會把redirect_uri和token帶到跳轉頁面 （這裏的跳轉頁面還是github自己的），跳轉頁面的服務端程序要用redirect_uri來生成一個token，看看是不是和傳來的token是一 個樣的。這就是所謂的對URL進行簽名——以保證URL的不被人篡改。一般來說，對URL簽名和對簽名驗證的因子包括，源IP，服務器時間 截，session，或是再加個salt什麼的。 第三個BUG — 注入跨站圖片現在，redirect_uri帶着code，安全順利地跳到了Egor構造的網頁上：
但是，這個是gist的網頁，你無法在這個頁面上運行前端（Javascript）或後端程序（Ruby——Github是Ruby做的），現在的問題是我們怎麼得到那個code，因爲那個code雖然後帶到了我的網頁上來，但那個網頁還是github和用戶自己的環境。 到這裏，一般來說，黑客會在這個頁面上放一個諸如下面的一個鏈接，來引誘用戶點擊，： <a href=http://hack.you.com/>私人照片</a> 這樣，當頁面跳轉到黑客的網站上來後，你之前的網頁上的網址會被加在http頭裏的 Refere 參數裏，這樣，我就可以得到你的token了。 但是，在gist上放個鏈接還要用戶去點一下，這個太影響“用戶體驗”了，最好能嵌入點外部的東西。gist上可以嵌入外站的圖片，但是github的開發人員並非等閒之輩，對於外站的圖片，其統統會把這些圖片的url代理成github自己的url，所以，你很難搞定。 不過，我們可以用一個很詭異的技巧：
這個是什麼玩意？這個是個URL的相對路徑。但是爲什麼會有三個///呢？呵呵。 像程序員一樣的思考 這個時候，我們需要以“程序員的編程思維”來思考問題——如果你是程序員，你會怎麼寫校驗URL的程序？你一定會想到使用正則表達式，或是用程序來匹配URL中的一些pattern。於是，
好了，如果coolshell.cn網頁中的<img src=>或<a href=>中用到的相對路徑是 /host.com，那麼瀏覽器會解釋成：http://coolshell.cn/host.com，如果是///host.com，那麼就應該被瀏覽 器解釋成 http://coolshell.cn///host.com。 但是，Chrome和Firefox，會把///host.com當成絕對路徑，因爲其正確匹配了絕對路徑的scheme。如果你正在用Chrome/Firefox看這篇文章 ，你可以看看下面的連接（源碼如下）：
關鍵是，這個Chrome/Firefox的問題被標記成了Won’t Fix，我勒個去，基本上來說，後臺的程序也有可能有這樣的問題，對於Perl，Python，Ruby，Node.js，PHP帶的URL檢查的函數庫都有這樣的問題。 於是，我們就可以使用這樣的方式給gist注入了一個第三方站點的圖片（github的服務端沒有察覺到（因爲我們前面說過大多數語言的URL檢查 庫都會被 Bypass了），但是瀏覽器端把這個鏈接解釋到了第三方的站點上），於是請求這個圖片的http頭中的refere 中包含用戶當前頁面的URL，也包含了用戶授權的code。 到這裏，黑客Egor已經拿到用戶gist的權限並可以修改或查看用戶私用的gist了。但是作者並沒有滿足，他想要的更多。 第四個bug – Gist把github_token放在了cookie裏 於是Egor在用戶的cookie裏找到了 github_token
但是這個token沒什麼用，因爲授權的Scope只有gists。但是，這個token不應該放在用戶端的cookie裏，本身就是一個安全事故，這個東西只能放在服務端（關於Web開發中的安全事項，可以看看這篇文章《Web開發中的你需要了解的東西》）。 於是，Egor只能另謀出路。 第五個Bug – 自動給gist授權 因爲gist是github自家的，Egor所以估計github想做得簡單一點，當用戶訪問gist的時候，不會出彈出一個OAuth的頁面來讓 用戶授權，不然，用戶就會很詫異，都是你們自家的東西，還要授權？所以，Egor猜測github應該是對gist做了自動授權，於是，Egor搞了這樣 的一個URL（注意其中的 redirect_uri中的scope ）
於是，這個redirect-uri不但幫黑客拿到了訪問gist的token，而且還把授權token的scope擴大到了用戶的代碼庫等其它權限。於是你就可以黑入用戶的私有代碼區了。 其它 & 感想於是，作者從 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）你可以上去挨個看看他們找到的問題，你會發現好些安全問題都很小，有些只能說是不是很規範的問題，Github都賞了幾百刀。我查看了一下github的賞金政策，github賞金至少100刀，到5000刀不等。
讓我們捫心自問一下，我們花了多少時間在玩那些“紅包遊戲”，而又搞到了多少紅包？人家4個小時找了5個bug，掙了$4000美金。老天給了你我一樣的時間，我們用來抽幾塊錢的紅包，人家用自己的技能來掙獎金。這就是人和人的差距。這就是所謂的效率——你可以移步看看我寫的《加班與效率》 原文鏈接：http://coolshell.cn/articles/11021.html |
