Github 是目前相對最大的、使用人數(shù)最多的“男性交友平臺”，呸！說錯了，是“代碼托管交流平臺”，上面充斥著各種各樣的代碼和信息，可謂“寶藏平臺”。對于滲透測試人員來說，Github 最大的價值是在于滲透測試時利用其進行信息搜集工作，比如查找目標系統(tǒng)的源碼、數(shù)據(jù)庫地址、用戶名口令等等敏感信息。但是對于工作在甲方或者說擔(dān)任安全工作的各工程師、負責(zé)人來說，這無疑是最痛苦的和需要投入大量人力、物力的地方。

　　很多介紹企業(yè)安全建設(shè)或者安全架構(gòu)體系之類的文章和書籍都會講到關(guān)于 Github 監(jiān)控的事情，越來越多的安全人員開始去關(guān)注 Github 上面是否有自己單位業(yè)務(wù)的相關(guān)代碼和信息被泄露，監(jiān)控和巡檢形式多種多樣，如人工登錄按照關(guān)鍵字篩查，也可以利用開源工具進行自動化監(jiān)控巡檢，如 VIPKID 的 Github Monitor 以及 Hell0W0rld0 的 Github-Hunter 等等。但是難點和痛點其實不是前面說的這些工作，而是發(fā)現(xiàn)泄露后的排查分析和人員定位，如果泄露的內(nèi)容中有上傳者的相關(guān)信息那還好辦，能夠聯(lián)系上，讓其刪掉。但是對于任何上傳者信息都找不到的情況怎么辦呢？

　　這時候我們就要另辟蹊徑了，如果花費了很多時間后仍然找不到上傳者本人信息，無法聯(lián)系進行刪除，那么就需要聯(lián)系 Github 官方進行申訴了，讓 Github 官方進行核實和刪除，避免信息被大范圍的泄露。

　　01

　　首先，Github 官方提供了一些列刪除政策的說明。這里我介紹下我常用的兩種 DMCA 刪除政策和敏感數(shù)據(jù)刪除政策。鏈接如下：

　　https://docs.github.com/cn/github/site-policy/dmca-takedown-policy

　　https://docs.github.com/cn/github/site-policy/github-sensitive-data-removal-policy

　　什么是 DMCA？

　　DMCA 為托管用戶生成內(nèi)容的服務(wù)提供商提供了安全港。 僅僅一項侵犯版權(quán)的索賠就可能導(dǎo)致高達 150,000 美元的法定賠償，因此，對用戶生成的內(nèi)容承擔(dān)責(zé)任可能對服務(wù)提供商非常不利。 如果面向數(shù)以百萬計的用戶，這種潛在損失將不可估量，可以說，假如沒有 DMCA，則 YouTube、Facebook 或 GitHub 等云計算和用戶生成內(nèi)容的網(wǎng)站可能就不會存在或者至少會將部分成本轉(zhuǎn)嫁給用戶）。

　　DMCA 通過為托管涉嫌侵權(quán)用戶生成內(nèi)容的互聯(lián)網(wǎng)服務(wù)提供商建立版權(quán)責(zé)任安全港，解決了這一問題。 從本質(zhì)上講，只要服務(wù)提供商遵守 DMCA 的通知和刪除規(guī)則，就不會對基于用戶生成內(nèi)容的侵權(quán)行為承擔(dān)責(zé)任。 因此，對 GitHub 而言，保持其 DMCA 安全港狀態(tài)非常重要。

　　什么是敏感數(shù)據(jù)？

　　就本文檔而言，“敏感數(shù)據(jù)”是指符合以下條件的內(nèi)容：應(yīng)該保密，并且一旦公開，會對您或您的組織造成特定安全風(fēng)險。

　　敏感數(shù)據(jù)刪除請求適用于：

• 可訪問您組織的服務(wù)器、網(wǎng)絡(luò)或域的訪問憑據(jù)，例如用戶名與密碼組合、訪問令牌或其他敏感密鑰。
• 可代表您訪問第三方的 AWS 令牌和其他類似訪問憑據(jù)。 您必須能夠證明該令牌確實屬于您。
• 對組織構(gòu)成特定安全風(fēng)險的文檔（例如網(wǎng)絡(luò)圖）。 內(nèi)部服務(wù)器名稱、IP 地址和 URL 本身不夠敏感；您必須能夠證明內(nèi)部服務(wù)器名稱在特定文件或代碼段中的使用構(gòu)成了安全威脅。

　　兩者的區(qū)別是：DMCA 刪除政策偏向于涉嫌版權(quán)侵權(quán)的申訴，只接受針對受版權(quán)保護的作品并且標識出具體版權(quán)，涉及面可能是整個倉庫，而敏感數(shù)據(jù)刪除政策偏向于一些應(yīng)該保密但是被公開且易造成安全風(fēng)險的信息，比如用戶名和密碼、網(wǎng)絡(luò)拓撲圖等，基本上是一些代碼片段和部分內(nèi)容，很少會涉及整個倉庫。

　　02

　　如果內(nèi)部員工或者外部惡意人員上傳了本組織內(nèi)部擁有版權(quán)的一些產(chǎn)品或者系統(tǒng)的源代碼，在無法定位的情況下可以通過向 Github 官方提交 DMCA 刪除的請求。

　　流程：

　　DMCA 框架有點像課堂上傳紙條。 版權(quán)所有者向 GitHub 提交對某個用戶的投訴。 如果書寫正確，我們會將該投訴轉(zhuǎn)達給用戶。 如果用戶對投訴有異議，他們可以回傳“紙條”表達異議。 除了確定通知是否符合 DMCA 的最低要求外，GitHub 在此過程中幾乎不行使酌處權(quán)。 當(dāng)事方（及其律師）應(yīng)負責(zé)評估其投訴的合理性，并注意，此類通知受偽證處罰條款約束。

　　流程步驟：

• 版權(quán)所有者調(diào)查

　　版權(quán)的所有者即代碼被泄露的組織必須要進行初步調(diào)查，確保 github 上的內(nèi)容是未經(jīng)授權(quán)的且侵權(quán)的內(nèi)容。

• 版權(quán)所有者發(fā)送通知

　　在進行初步調(diào)查后，需要編寫刪除通知并發(fā)送到 Github 官方。如果符合法律要求并且內(nèi)容填寫足夠詳細，將會將該通知發(fā)布到公共倉庫 https://github.com/github/dmca，同時將連接發(fā)給受影響的用戶（上傳者）。之前 Github 提供了兩種發(fā)送通知的方式：郵件和在線提交，但是目前郵件發(fā)送的方式取消了，不再支持了，所以只有在線提交刪除通知這一種形式了。后面會詳細介紹如何提交這些內(nèi)容。

• Github 要求上傳者進行更改

　　如果刪除通知指明整個倉庫內(nèi)容都涉及侵權(quán)，那么將會直接到步驟 6 迅速禁用整個倉庫。否則會聯(lián)系上傳人，給其 1 個工作日的時間來刪除或修改刪除通知中指定的內(nèi)容，同時通知版權(quán)所有者。

• 上傳者向 Github 通知更改

　　上傳者如果選擇進行制定內(nèi)容的更改，必須要在 1 個工作日內(nèi)告知 githuba 官方，否則會禁用整個倉庫，如果上傳者更改了，也會發(fā)送通知給版權(quán)所有者。

• 版權(quán)所有者修改或撤回通知

　　上傳者進行更改后，版權(quán)所有者必須進行審查，如果認為更改不充分，可以重申或者修改刪除通知。除非版權(quán)所有者聯(lián)系 github 重申或修改通知，否則 github 不會采取任何進一步的動作。如果版權(quán)所有者對更改感到滿意，可以提交正式的撤回聲明，或者什么都不做，靜默期超過兩周，github 將默認撤回刪除通知。

• Github 可能禁止訪問內(nèi)容

　　在以下情況下，Github 將會禁用上傳者的內(nèi)容：（1）版權(quán)所有者生成對整個倉庫擁有版權(quán)；（2）上傳者在收到整改通知后并沒有進行任何更改；（3）版權(quán)所有者在上傳者更改后重申了刪除通知。

• 上傳者可發(fā)送反通知

　　上傳者收到整改通知后如果認為錯誤指認而被禁用，可以向 Github 發(fā)起反通知，當(dāng)然內(nèi)容也要最夠詳細。也會發(fā)布到 github 官方的公共倉庫，并且通知給版權(quán)所有者。

• 版權(quán)所有者可提出法律訴訟

　　如果版權(quán)所有者在收到反通知后，如果希望繼續(xù)刪除或禁用該內(nèi)容，則可以發(fā)起法律訴訟，需求法律幫助制止上傳者從事的相關(guān)侵權(quán)互動。如果版權(quán)所有者 10-14 天內(nèi)沒有想 Github 發(fā)出通知（向法院提交的訴訟副本），Github 將重新啟用被禁用的內(nèi)容。

　　03

　　按照 02 章節(jié)的流程步驟，我們進行初步調(diào)查后，確定是自己組織內(nèi)產(chǎn)品或系統(tǒng)的代碼或者相關(guān)信息后，就可以向 Github 官方提出申訴了。Github 對于提交 DMCA 刪除有以下要求指南：

　　開始前…….

• 說實話

　　這個很重要。DMCA 要求對版權(quán)投訴中陳述的事實宣誓，捏造事實會受到偽證處罰。在宣誓中故意說謊是一種違反聯(lián)邦法律的罪行。提交虛假信息還可能導(dǎo)致民事責(zé)任，也就是說可能被起訴經(jīng)濟賠償。所以在進行 DMCA 刪除申訴前一定要認真核實代碼等信息，百分百確定是被侵權(quán)的內(nèi)容且有相關(guān)版權(quán)的證明。

• 調(diào)查

　　DMCA 投訴是一種嚴重的法律質(zhì)控，所以在提交刪除申訴前一定要認真調(diào)查。

• 先問清

　　在發(fā)送刪除申訴前嘗試直接聯(lián)系用戶，是一個良好的開端。當(dāng)然，在沒有上傳者信息的情況下，可以在倉庫中新建 issue，取得聯(lián)系。這個不是強制要求，但是卻很有效果，如果沒有提前聯(lián)系，官方處理時間會延遲 10 天左右，不會優(yōu)先處理。

• 發(fā)送正確請求

　　只接受針對受版權(quán)保護的作品并標識出具體版權(quán)作品的 DMCA 刪除通知。如果要投訴商標濫用、刪除敏感信息請參考其對應(yīng)的政策要求。

• 代碼不同于其他創(chuàng)意內(nèi)容

　　Github 是軟件代碼寫作的平臺。因此，在這里識別有效的版權(quán)行為，比識別照片、音樂或視頻等方面的版權(quán)侵權(quán)行為要復(fù)雜的多。

• 不要使用自動程序

　　應(yīng)該讓專業(yè)人員來評估發(fā)送的每個刪除通知申訴的內(nèi)容。也不要使用自動化程序和工具進行批量申訴提交，這些提交往往是無效的。

• 版權(quán)問題難以確定

　　比如一些字詞短語、URL 和域名通常不受版權(quán)保護，所以提交之前建議咨詢下律師等專業(yè)人士，給出一些參考意見。

• 你可能會收到反通知

　　前面第 02 章節(jié)提到，如果上傳者認為是被錯誤指認的，可以提出反通知，也會發(fā)送給版權(quán)所有者

• 你的投訴將被公布

　　投訴被接受后，會將投訴公布在 https://github.com/github/dmca 這個倉庫中。

• Github 不是法官

　　Github 在整個過程中，除了確定是否符合 DMCA 最低要求外，幾乎不行使酌處權(quán)。當(dāng)事方（及其律師）應(yīng)負責(zé)評估其投訴的合理性，并注意，此類通知受偽證處罰條款約束。

　　投訴必須包括如下內(nèi)容：

• 包括以下聲明：“我已閱讀并理解 Github 的《提交 DMCA 通知指南》。”如果申訴未包括此聲明，但是其他內(nèi)容完整，Github 不會拒絕處理，但是會要求先完成閱讀指南。
• 標識出被侵權(quán)的作品。這條就是說版權(quán)所有者要把自己的版權(quán)信息具體標識出來，如果是已經(jīng)發(fā)布的，需要將鏈接發(fā)出來，如果是尚未發(fā)布的專有信息，可以對其進行詳細描述并說明他是專有信息。如果已經(jīng)在版權(quán)局注冊，則應(yīng)提供注冊號。當(dāng)然了如果托管的內(nèi)容完全是直接復(fù)制作品，也可以只闡述這一事實，但如果只寫這一句話，處理時間估計會延長。
• 標識聲稱侵犯了上述第 2 條中所列版權(quán)作品的材料。這一步就是說要詳細的把侵權(quán)的內(nèi)容標識出來，要讓 Github 官方能夠找到所指的內(nèi)容。比如應(yīng)該包括涉嫌侵權(quán)的 URL。如果不是整個倉庫都侵權(quán)，需要標識出具體的文件或者文件中的行號和具體信息。當(dāng)然，如果所有該 URL 的所有內(nèi)容都侵權(quán)也需要明確說明。需要注意的是，Github 在禁用父倉庫時，不會禁用 fork 的內(nèi)容，如果調(diào)查分析了 fork 的內(nèi)容也涉嫌侵權(quán)，需要明確標識出涉嫌侵權(quán)的 fork。
• 說明侵權(quán)用戶需要采取哪些補救措施。這個就是一旦查明上傳者侵權(quán)屬實，那我們版權(quán)所有者需要上傳者做的動作和要求。比如，用戶只需添加歸屬聲明、刪除代碼中的某些行、刪除整個倉庫等都需要明確說明。
• 提供申訴人的聯(lián)系信息。包括電子郵件地址、姓名、電話號碼和實際地址。
• 提供涉嫌版權(quán)者的聯(lián)系信息（如果知道）。一般是通過提供上傳者的 Github 用戶名來滿足要求，當(dāng)然如果知道更多的信息也可以提供出來。
• 最后聲明：“我堅信，在侵權(quán)網(wǎng)頁上使用上述版權(quán)材料，未經(jīng)版權(quán)所有者、其代理人或法律的授權(quán)。我已考慮合理使用的情況。”以及宣誓：“本人謹此宣誓，本通知中的信息準確無誤，對于涉嫌受到侵犯之專有權(quán)，本人是所有者或者所有者的授權(quán)代表，如有不實，愿接受偽證處罰。”
• 提供手寫或電子簽名。

　　04

　　之前，Github 還接受郵件申訴，但是現(xiàn)在不支持了，前幾天發(fā)了一封申訴郵件，發(fā)完立刻收到回信，表示郵件方式已經(jīng)不再受理了。

　　所以，只能使用在線申訴。。

　　地址：https://support.github.com/contact/dmca-takedown

　　這里面的內(nèi)容和第 03 章節(jié)中投訴必須包括如下內(nèi)容：是一致的，可能順序稍微有點不太一樣，但是影響不大，只要按照每個標題提示輸入相應(yīng)的內(nèi)容即可，在這里明確一點，我提供的截圖是翻譯成中文版的，原始頁面是英文，而且大家在申訴填寫相關(guān)內(nèi)容時也要填寫英文，不能輸入中文，畢竟老美看不懂。遇到不會的詞或句子可以通過翻譯工具翻譯后貼上。

　　成功提交后，很快會收到 Github 的回信。類似這樣：

　　然后等著就行了。

　　05

　　接下來，再總結(jié)下敏感數(shù)據(jù)刪除的一些過程內(nèi)容。

　　敏感數(shù)據(jù)刪除主要指的是一些保密銘感信息，比如組織的網(wǎng)絡(luò)拓撲圖、系統(tǒng)的用戶名和密碼等等，如果這些信息數(shù)據(jù)被上傳者上傳到了 Github，無法定位上傳人員的情況下，可以向 Github 官方發(fā)起敏感數(shù)據(jù)刪除申訴。敏感數(shù)據(jù)的刪除要求和流程步驟基本上和 DMCA 刪除的差不多，也是調(diào)查分析、發(fā)起請求、不能使用自動程序、用戶整改等等，但是比 DMCA 的稍微簡單點，這里不再贅述，詳細了解可參考 https://docs.github.com/cn/github/site-policy/github-sensitive-data-removal-policy。

　　敏感數(shù)據(jù)刪除請求需要包括如下內(nèi)容：

1. 每個包含敏感數(shù)據(jù)文件的可點擊的有效鏈接。不能是搜索的結(jié)果、示例或者截圖。
2. 每個文件中包含敏感數(shù)據(jù)的具體行號。
3. 描述每條敏感信息對你或者組織構(gòu)成的安全風(fēng)險。不僅要指出敏感數(shù)據(jù)，還要解釋這些數(shù)據(jù)如何構(gòu)成安全風(fēng)險，這個很重要。
4. 如果您是代表面臨安全風(fēng)險之組織行事的第三方，需要附上聲明，表面具有代表該組織行事的合法權(quán)利。
5. 可選：如果請求非常急迫，需要說明原因。

　　在線刪除請求的地址 https://support.github.com/contact

　　根據(jù)要求在輸入框中輸入敏感數(shù)據(jù)要求包括的內(nèi)容和期望的動作即可。同樣也是必須要使用英文填寫的。

　　以上就是在處理 Github 代碼和信息泄露時，如果定位不到上傳人時，經(jīng)常用到的兩個刪除申訴的過程要求和一些需要注意的點。如果不按官方的要求來，要么會拒絕處理，要么是等待時間很長很長，所以一定要把申訴內(nèi)容準備的充分一點。希望我總結(jié)分享能夠幫助到有需要的人。

　　最后，也希望大家積極和我交流，共同提高！

總結(jié)

以上是生活随笔為你收集整理的Github提交删除代码请求的申诉总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。