本文不涉及常見的基于代碼關(guān)鍵字匹配的 GitHub 監(jiān)控。而是從 GitHub 的賬戶出發(fā)，通過人的關(guān)系來獲得一些代碼搜索不具有的優(yōu)勢。 

　　疑云乍現(xiàn)

　　問題要從一個晴朗而又嫵媚的下午說起，我喝著娃哈哈，看著自認(rèn)為世界上***雅的代碼，然而當(dāng)我上傳到 GitHub 私有倉庫的時候，嘴角的一抹笑意停留在 10 秒 24 毫秒前的陽光下，因為我發(fā)現(xiàn)上傳顯示的用戶并非是我，換句話說，commit 頁面并未顯示我?guī)洑獾念^像，我的職業(yè)第二敏感性告訴我，這個事情有點蹊蹺：

a.這個人是誰？

b.我的機器被劫持了？

c.我的賬戶被黑了？

d.GitHub 出問題了？

e.某些未知原因？

　　a 問題是比較好回答的，點進(jìn)去發(fā)現(xiàn)是一個非常正常的用戶，我總不至于被黑了，不行，職業(yè)尊嚴(yán)讓我強制排除了這個選項，但是我比較關(guān)心的一個問題是 ta 是不是能看到我的代碼？ta 會不會因為如此優(yōu)雅的代碼而感到自愧不如？所以隨后出于對他情感的考慮先清空了自己的代碼。

　　對于b，更換了多臺機器，發(fā)現(xiàn)仍然具有相同的問題，同樣出于職業(yè)尊嚴(yán)，我的機器不可能都被黑了，所以問題堅決不在b。 

　　隨后又細(xì)細(xì)過濾了最近的 GitHub 登錄記錄，c的可能性也被排除了；再問周圍的童鞋，d的問題也被排除了。

　　目前只剩下e原因，但是這句話其實相當(dāng)于沒有說，因為一切未知都能歸結(jié)到未知。

　　刨根問底

　　問題在這已經(jīng)陷入了死胡同，簡單描述下就是：因為某些未知原因，我的 GitHub 的提交人變成了未知的某人，而且在換了多臺機器之后，問題依然重復(fù)。一般遇到這種情況，我的習(xí)慣都是從頭梳理整個流程，從全局分析可能存在問題的環(huán)節(jié)。當(dāng)務(wù)之急是需要重新梳理下所有的流程，然后不斷嘗試，那么問題來了，從編寫代碼到下載 Git 并使用 Git 提交到 GitHub 的流程是什么呢？

　　Git 首先需要下載到本地，下載本地的時候需要使用 HTTP 協(xié)議，HTTP 協(xié)議是基于 TCP 的，說到 TCP，那么就要了解三次握手…….

　　半小時后……

　　看著 16 位微處理器芯片 8086 微處理器總線接口部分(BIU) 和執(zhí)行部件(EU)知識的我……感覺再深挖下去估計要開始學(xué)習(xí)二氧化硅的化學(xué)反應(yīng)了，呵，知識啊。 

　　只好另辟蹊徑，找了一個熟悉 Git 的強力外援，我們先嘗試了……然后嘗試了……接著又嘗試了……終于功夫不負(fù)有心人，找到了***的癥結(jié)所在。不是故意跳過這段，實在是這個過程乏善可陳。

　　總之看下邊重點了：

　　這個問題引發(fā)的根本原因是使用某發(fā)行版源倉庫安裝的 Git 默認(rèn)內(nèi)置了一個郵箱和用戶名，然后 GitHub 在上傳的時候識別用戶是默認(rèn)通過 Git 中配置的郵箱來識別，倘若用戶郵箱存在（在 GitHub 注冊或者登記）則顯示匹配到的用戶名，否則會顯示 Git 配置中的用戶名，驗證之后發(fā)現(xiàn)這個郵箱不一定是注冊郵箱，而是在設(shè)置里添加的都可以關(guān)聯(lián)到，也就是剛剛提到的登記郵箱，即使你沒有驗證郵箱的歸屬權(quán)限，如下圖：

　　而且尤其比較詭異的是使用 Git config user.name 和 Git config user.email 這兩個命令查看均顯示為空，就像這個命令從未執(zhí)行一樣，但是在使用 Git log 的時候才會真正顯示提交本次 commit 的用戶名和郵箱，也就是該發(fā)行版 Git 內(nèi)置的缺省賬戶和郵箱。

　　撥云見日

　　上邊說了那么多，那么這個東西有什么用呢？我一直秉承一個觀點：安全總是跟場景相關(guān)的，所以要想知道這個有什么危害，首先需要做的就是設(shè)想一些可利用的場景。

　　在這里最基本的利用方式是可以偽造別人去提交代碼，但是這個對我們來說其實并沒有什么太大的用處。準(zhǔn)確來說，更多有一種惡作劇的味道。

　　那有沒有什么其他的場景是比較有用的，其實在寫這篇文章之前，我還是比較猶豫的，眾所周知，GitHub 有很多用戶提交了一些比較敏感的東西，而作者是不想在現(xiàn)實中被發(fā)現(xiàn)的，但是上述提到這個接口，可以通過批量爆破郵箱從而獲得對應(yīng)的用戶名。那么也有可能獲得了那些不愿意公開自己身份用戶的聯(lián)系方式。

　　扯的有點遠(yuǎn)了，還是回歸到題目當(dāng)中 GitHub 監(jiān)控的問題，當(dāng)前 GitHub 監(jiān)控一直是基于代碼搜索中的關(guān)鍵字匹配，真的是誰用誰知道——那是相當(dāng)?shù)碾y用。所以目前很多人也是在爬蟲和更好的過濾上下功夫。但是這個流程還有一個盲點存在，就是在發(fā)現(xiàn)違規(guī)上傳的***時間并不能特別準(zhǔn)確的定位到具體的個人。

　　說完傳統(tǒng)監(jiān)控的缺陷同時，我們其實也找到了新的利用場景，因為入職信息登記都會寫到自己的常用郵箱（還沒有入職，所以基本填寫自己私人常用郵箱），那么可以通過這個接口來獲得對應(yīng)的用戶賬戶，換句話說，安全團(tuán)隊基本就有了部分員工注冊的 GitHub 賬戶，這個時候違規(guī)上傳公司代碼的監(jiān)控是不是可以做一些分級管理，重點監(jiān)控。而且更重要的一點，這也解決了發(fā)現(xiàn)問題簡單、定位人員困難的問題。

　　至于操作過程，就相當(dāng)簡單了，新建一個項目，然后使用腳本修改自己用戶郵箱進(jìn)行 commit，在這里我以修改自己的郵箱為例：

　　之后 push 到 GitHub 上去，***在 GitHub 上就可以看到綁定了對應(yīng)郵箱的用戶，如下圖（項目地址：https://github.com/daysdaysup/TSRC_TEST）：

　　至于剩下的就不用再多說了。套用一句比較流行的打油詩：懂的自然懂，刀劍俠客夢，事了拂衣去，深藏身與名。

　　***特別致謝我的師兄吳恒，感謝他在撰寫本文時提供的幫助。