原標題：前有“程序員刪庫跑路”，后有 CTO 在網站后臺引入 Bug，導致公司 1.5 萬賬戶信息外泄。

整理 | 蘇宓

出品 | CSDN(ID：CSDNnews)

近日，據外媒報道，美國開源社交網絡服務平臺 Gab 受到黑客攻擊，其中，包括一些知名人士在內的 1.5 萬 Gab 賬號及個人信息遭到泄露。

據悉，一位未透露姓名的黑客利用 SQL 注入漏洞入侵 Gab 后臺，并從數據庫中竊取了約 70 GB 數據提供給了爆料組織 Distributed Denial of Secrets(簡稱 DDOSecrets)。這些數據包括了 7 萬多條信息、4000 多萬條帖子，以及哈希密碼、明文密碼、用戶個人資料等。

然而，在 Gab 公司審查并欲修復漏洞之際，竟然發(fā)現此 Bug 出自自家公司的 CTO 之手，而這究竟又是怎么一回事?

CTO 寫的 Bug，后果很嚴重!

正如上文所述，Gab 公司在遭到黑客攻擊后，爆料組織 DDOSecrets 團隊公開發(fā)文表示，“正在將這些泄露的數據匯編成了一個 GabLeaks 的文件，同時將對外分發(fā)共享此數據集，記者、學者以及研究者可以通過公開渠道與其獲得聯系，對這些信息進行研究學習?！?/p>

在知曉這一消息之后，Gab 創(chuàng)始人 Andrew Torba 發(fā)表聲明強烈譴責了相關的組織以及傳播的記者。

不過，就在譴責泄露組織及相關人員之際，Gab 內部也對網站的整體安全進行了審查。然而萬萬沒想到的是，在快速瀏覽了 Gab 的開放源代碼之后，竟然發(fā)現關鍵漏洞(至少有一個非常類似的漏洞)是源自 Gab CTO 提交的代碼。

據外媒報道，通過查看 Gab 公司提交的“Git commit”更改記錄中發(fā)現，今年 2 月，有一個名為 Fosco Marotto 的軟件開發(fā)者，提交了一份代碼。在這份代碼中存在一個很明顯的錯誤類型，而這往往是新手才容易犯的錯誤，即第 23 行代碼中，拆分了“reject”和“filter”代碼，這兩個 API 函數實現了防止 SQL 注入攻擊的編程習慣。

這種慣用的方法可以幫助程序員能夠以安全的方式編寫 SQL 查詢功能，且可以“清理”網站訪問者在搜索框和其他 Web 網站中輸入的字段，借此來確保在將文本傳遞給后端服務器之前，先清除掉所有惡意命令。

不過，開發(fā)者也需要向一個包含“find_by_sql” 方法的 Rails 函數添加了一個調用，這一方法直接在查詢字符串中接受未經過濾的輸入(Rails 是一種廣泛使用的網站開發(fā)工具包)。

對此，Facebook 的前產品工程師 Dmitry Borodaenko 在一封電子郵件中寫道，“ 或許 Rails 的官方文檔沒有警告過用戶存在這個陷阱，但是，如果作為開發(fā)者，完全了解在 Web 應用程序中使用 SQL 數據庫的任何知識，那么，相信你也聽說過 SQL 注入，由此也不難發(fā)現“find_by_sql”方法不正確的警告?！?/p>

同時， Dmitry Borodaenko 指出，“現在并非能夠 100% 確認這是在 Gab 數據泄露中使用的漏洞，但是不排除可能性，現在 Gab 團隊已經將其在 GitLab 存儲庫中提交的最新代碼恢復到了上一版本 。”

那么，要問 Fosco Marotto 是何許人也?

據悉，Fosco Marotto 此前在 Facebook 作為軟件工程師任職 7 年，2020 年 11 月，正式加入 Gab 平臺擔任 CTO 一職。針對上面所犯的錯誤，也頗具有諷刺意義的是，Fosco 曾在 2012 年提醒過其他程序員，一定要使用參數化查詢來防止 SQL 注入漏洞。

如今，Gab 已從其網站刪除了 Git commit。

修正主義者的歷史

然而又是這一舉措，Gab 再次成為眾矢之的。

作為一家創(chuàng)業(yè)型的開源社交網絡服務平臺，其支持言論自由，也一直被視為 Twitter 的最佳替代品，不過，Gab 此次在沒有任何解釋之下，直接刪除提交的代碼，引發(fā)業(yè)界不小爭議。

對此，有批評人士稱，此舉違反了 Affero 通用公共許可的條款，該許可將規(guī)范 Gab 對 Mastodon(用于托管社交網絡平臺的開源軟件包)的重用。

據公開資料顯示，GNU Affero 通用公共許可協(xié)議是一個廣泛被使用的自由軟件許可協(xié)議，其改自 GNU 通用公共許可協(xié)議，并加入額外條款，其目的是為了 Copyleft 條款應用于在網絡上運行的應用程序(如 Web 應用)，從而避免有人以應用服務提供商方式逃避 GNU 通用公共許可協(xié)議。

批評人士表示，Gab 的刪除行為違反了要求從網站直接鏈接到分叉源代碼的條款。這些要求旨在提供公開、透明度，并使其他開放源代碼開發(fā)者可以從 Gab 的同行中受益。

據報道，Gab 一直都是在 https://code.gab.com/ 上提交代碼的。

但是，本星期一，Gab 突然刪除了所有提交，包括那些創(chuàng)建并修復了嚴重 SQL 注入漏洞的提交。取而代之的是，Gab 使用了 Zip 存檔文件的形式提供了源代碼，該文件受密碼“ JesusChristIsKingTrumpWonTheElection”的保護。

截止目前，據 Gab Git commit 顯示，該公司的開發(fā)者也正在努力修復其易受攻擊的代碼。正如下圖所示，一位用戶名為“ developer”的開發(fā)者正在嘗試完全修復包含 SQL 注入漏洞的代碼，但最終并未成功。

網友：不足為奇

針對這樣的錯誤，也引發(fā)了不少網友的討論：

一點都不足為奇。在某一時刻，當他們有一個 API 時，我可以跟蹤和看到在網站上看不到的"鎖定"帳戶中的信息。我對他們網站反饋了這一問題，他們回復說：“哦， 是的， 我們現在正在做很多改變，”然后從來沒有修復過這一 Bug。

對于企業(yè)而言，CTO 應該專注于戰(zhàn)略層面，手里下應該會有 1-2 位開發(fā)者來領導日常的開發(fā)工作，并針對此類基本問題(或使用代碼分析器)進行代碼審查，以檢測 sql、xss、xsrf、會話管理、基于密碼的用戶數據加密、消息加密和其他瑣事。這并不是說我喜歡 Gab 這家公司，但我不知道有多少這樣的新手錯誤，然后最終會被歸咎于"外包公司"。

這是糟糕的代碼， 有點讓我吃驚的是， 一個前 Facebook 工程師寫了它 (后來成為 CTO)，顯然，Gab 并沒有雇傭到一位最優(yōu)秀、最聰明的 CTO。

對此，你怎么看?

免責聲明：本文內容由21ic獲得授權后發(fā)布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯系我們，謝謝!