朗讀老大寫出低級 Bug，致公司 70 GB 隱私遭泄露第老大寫出低級 Bug，致公司 70 GB 隱私遭泄露

《老大寫出低級 Bug，致公司 70 GB 隱私遭泄露》
骷髏心據悉，一位未透露姓名的黑客利用 SQL 注入漏洞入侵 Gab 後台，並從數據庫中竊取了約 70 GB 數據提供給了爆料組織 Distributed Denial of Secrets（簡稱 DDOSecrets）。這些數據包括了 7 萬多條信息、4000 多萬條帖子，以及哈希密碼、明文密碼、用戶個人資料等。然而，在 Gab 公司審查並欲修複漏洞之際，竟然發現此 Bug 出自自家公司的 CTO 之手，而這究竟又是怎麼一回事？
CTO 寫的 Bug，後果很嚴重！正如上文所述，Gab 公司在遭到黑客攻擊後，爆料組織 DDOSecrets 團隊公開發文表示，“正在將這些泄露的數據匯編成了一個 GabLeaks 的文件，同時將對外分發共享此數據集，記者、學者以及研究者可以通過公開渠道與其獲得聯系，對這些信息進行研究學習。”在知曉這一消息之後，Gab 創始人 Andrew Torba 發表聲明強烈譴責了相關的組織以及傳播的記者。
不過，就在譴責泄露組織及相關人員之際，Gab 內部也對網站的整體安全進行了審查。然而萬萬沒想到的是，在快速瀏覽了 Gab 的開放源代碼之後，竟然發現關鍵漏洞（至少有一個非常類似的漏洞）是源自 Gab CTO 提交的代碼。據外媒報道，通過查看 Gab 公司提交的“Git commit”更改記錄中發現，今年 2 月，有一個名為 Fosco Marotto 的軟件開發者，提交了一份代碼。在這份代碼中存在一個很明顯的錯誤類型，而這往往是新手才容易犯的錯誤，即第 23 行代碼中，拆分了“reject”和“filter”代碼，這兩個 API 函數實現了防止 SQL 注入攻擊的編程習慣。
這種慣用的方法可以幫助程序員能夠以安全的方式編寫 SQL 查詢功能，且可以“清理”網站訪問者在搜索框和其他 Web 網站中輸入的字段，借此來確保在將文本傳遞給後端服務器之前，先清除掉所有惡意命令。不過，開發者也需要向一個包含“find_by_sql” 方法的 Rails 函數添加了一個調用，這一方法直接在查詢字符串中接受未經過濾的輸入（Rails 是一種廣泛使用的網站開發工具包）。對此，Facebook 的前產品工程師 Dmitry Borodaenko 在一封電子郵件中寫道，“ 或許 Rails 的官方文檔沒有警告過用戶存在這個陷阱，但是，如果作為開發者，完全了解在 Web 應用程序中使用 SQL 數據庫的任何知識，那麼，相信你也聽說過 SQL 注入，由此也不難發現“find_by_sql”方法不正確的警告。”同時， Dmitry Borodaenko 指出，“現在並非能夠 100％ 確認這是在 Gab 數據泄露中使用的漏洞，但是不排除可能性，現在 Gab 團隊已經將其在 GitLab 存儲庫中提交的最新代碼恢複到了上一版本 。”
那麼，要問 Fosco Marotto 是何許人也？據悉，Fosco Marotto 此前在 Facebook 作為軟件工程師任職 7 年，2020 年 11 月，正式加入 Gab 平台擔任 CTO 一職。針對上面所犯的錯誤，也頗具有諷刺意義的是，Fosco 曾在 2012 年提醒過其他程序員，一定要使用參數化查詢來防止 SQL 注入漏洞。如今，Gab 已從其網站刪除了 Git commit。修正主義者的歷史然而又是這一舉措，Gab 再次成為眾矢之的。作為一家創業型的開源社交網絡服務平台，其支持言論自由，也一直被視為 Twitter 的最佳替代品，不過，Gab 此次在沒有任何解釋之下，直接刪除提交的代碼，引發業界不小爭議。對此，有批評人士稱，此舉違反了 Affero 通用公共許可的條款，該許可將規範 Gab 對 Mastodon（用於托管社交網絡平台的開源軟件包）的重用。據公開資料顯示，GNU Affero 通用公共許可協議是一個廣泛被使用的自由軟件許可協議，其改自 GNU 通用公共許可協議，並加入額外條款，其目的是為了 Copyleft 條款應用於在網絡上運行的應用程序（如 Web 應用），從而避免有人以應用服務提供商方式逃避 GNU 通用公共許可協議。批評人士表示，Gab 的刪除行為違反了要求從網站直接鏈接到分叉源代碼的條款。這些要求旨在提供公開、透明度，並使其他開放源代碼開發者可以從 Gab 的同行中受益。
據報道，Gab 一直都是在 https://code.gab.com/ 上提交代碼的。但是，本星期一，Gab 突然刪除了所有提交，包括那些創建並修複了嚴重 SQL 注入漏洞的提交。取而代之的是，Gab 使用了 Zip 存檔文件的形式提供了源代碼，該文件受密碼“ JesusChristIsKingTrumpWonTheElection”的保護。截止目前，據 Gab Git commit 顯示，該公司的開發者也正在努力修複其易受攻擊的代碼。正如下圖所示，一位用戶名為“ developer”的開發者正在嘗試完全修複包含 SQL 注入漏洞的代碼，但最終並未成功。
網友：不足為奇針對這樣的錯誤，也引發了不少網友的討論：一點都不足為奇。在某一時刻，當他們有一個 API 時，我可以跟蹤和看到在網站上看不到的"鎖定"帳戶中的信息。我對他們網站反饋了這一問題，他們回複說：“哦， 是的， 我們現在正在做很多改變，”然後從來沒有修複過這一 Bug。對於企業而言，CTO 應該專注於戰略層面，手裏下應該會有 1-2 位開發者來領導日常的開發工作，並針對此類基本問題（或使用代碼分析器）進行代碼審查，以檢測 sql、xss、xsrf、會話管理、基於密碼的用戶數據加密、消息加密和其他瑣事。這並不是說我喜歡 Gab 這家公司，但我不知道有多少這樣的新手錯誤，然後最終會被歸咎於"外包公司"。這是糟糕的代碼， 有點讓我吃驚的是， 一個前 Facebook 工程師寫了它 （後來成為 CTO），顯然，Gab 並沒有雇傭到一位最優秀、最聰明的 CTO。整理 | 蘇宓出品 | CSDN
《老大寫出低級 Bug，致公司 70 GB 隱私遭泄露》完，請繼續朗讀精采文章。
喜歡 小編的世界 e4to.com，請記得按讚、收藏及分享！