|
本帖最後由 KinKALaw 於 2017-7-20 09:10 編輯
來源： 網絡收集
來源網址:請点擊
偽造commits實例分析快速演練為了給出一個可能出現的問題的快速示例，請考慮以下示例： 創建了一個新的存儲庫，並推出了一個初始提交。
從上圖中可以看出，我們提交電子郵件地址:john.poulin@nvisium.com
如果我們更改電子郵件地址並進行新的提交，會發生什麼？
.gitconfig更改為指向我們的CTO的帳戶
上圖修改.gitconfig中的Email地址為我們CTO的賬戶ken.johnson@nvisium.com
接下來，我們的目標是嘗試提交一些似乎是惡意代碼或包含安全漏洞的代碼。作為安全公司的首席技術官，承擔脆弱的代碼將是一個重要的罪惡。所以我們創建一個容易受到動態渲染的Rails控制器，並且代表它來推送它。
易受害的檔案已上傳(如下圖)
然後我們去github上查看提交歷史，看看有什麼有趣的事情發生，如下圖：
有一個更具說明性的例子，看看肯的存儲庫，他似乎在Linus Torvalds作為提交者。
這種情況的問題是，代表其他受信任的用戶很容易偽裝提交。例如，Ken可能比其他員工更加信任公司。因此，我們比從新僱員那裡更可能接受他的請求。這些公關部門的審查可能比初級開發人員提交的審查要少得多。
案例2：劫持GitHub提交我們發現的另一種情況是，在GitHub上，在某些情況下，您可以聲明舊電子郵件地址的所有權。例如，如果帳戶被停用，任何用戶都可以聲明與特定帳戶綁定的提交的所有權。例如，當我們承諾屬於我們的CTO的舊帳戶時，我們更早看到這種行為。 瀏覽我們的一個存儲庫後，我看到了Ken的帳號提交。當我通過GitHub打開它詢問我是否要求電子郵件地址。顯然，這引起了我的興趣，所以我做到了。
在聲明之後，我注意到我的帳戶設置已被列為“未驗證”。
在聲明他的帳戶時，我注意到他的所有承諾現在歸因於我。事實上，我的帳戶現在顯示比帳戶更早的提交
帳戶創建之前列出的提交(如下圖)
在這種情況下，我能夠要求不屬於我的承諾。如果我的公司使用Git提交的數量或頻率作為某種形式的性能指標，那麼很容易欺騙他們。
解決方案：解決commit 偽造的問題GitHub完全意識到這些情況，並認為他們是“有意設計的決定，正如預期的那樣工作”。實質上，Git協議是一個根本的問題，它不提供真正的提交認證。要清楚，這些情況不允許您與無權訪問的存儲庫進行交互。例如，我無法利用這些問題來劫持屬於私有存儲庫的提交。 從我與GitHub的幾個人的討論中，最好的解決方案是利用GPG簽署提交。Git的GPG簽名功能並不是僅僅接受這些提交，而是將Git帳戶的電子郵件地址與GPG密鑰相匹配，然後在將它們推送到服務器之前簽名。GitHub通過將簽名與您的已知公鑰進行比較來處理簽名提交，只要通過驗證，在提交旁邊顯示“已驗證”標誌。
我強烈建議您為您的帳戶啟用GPG簽名。按照Github的指南，很容易做到。 此外，如果您管理項目或對組織的安全性負責，我建議執行所有提交的規則必須進行簽名和驗證。這將有助於確保提交實際上屬於他們聲稱的用戶，而不是偽裝惡意代碼的所有權。
| 
發表於 2017-7-20 09:08:57
收藏
推
噓
提升卡
置頂卡
變色卡
搶沙發
千斤頂