堂堂一家公司的CTO，到底能水到什麼程度？因為一個低級錯誤，70GB大小的信息數據被洩露，公司還被黑客敲詐了50萬美元。而被發現後，他為了隱藏證據，竟還刪掉了代碼…這就是最近在一個社交媒體網站Gab上發生的真實事件。

上週末，黑客通過SQL注入漏洞入侵他們的官網，並竊取了15000位用戶的數據。

這其中還包括特朗普。

後經媒體調查發現，關鍵漏洞竟是由該公司的CTO造成的。

而這位CTO是一位入職不到半年，但有著23年開發經驗的工程師。

其前東家更是名牌“大廠”—— Facebook。

於是就有網友質疑，這是公司眼瞎了？還是CTO太水了？

大廠“畢業”CTO，犯下致命低級錯誤

而事件的起因，是一位黑客利用SQL注入漏洞入侵了公司後台，竊取了數據。

這其中包含用戶公開、私人的帖子、哈希密碼以及私人資料，共涉及70000條信息。

不光如此，黑客還將此事透露給了一個爆料網站DDoSecrets，與維基解密類似，從事披露黑客竊取的數據和機密信息等工作。

在事件公開之前，該網站的記者還在社交網絡上挑釁Gab的CEO Andrew Torba：

DDoSecrets甚至都沒有宣布任何消息，Gab就已經害怕了。

隨後，不少媒體、專家在調查了這家公司的git commit記錄之後發現，是一個名叫“Fosco Marotto”賬戶，更改了後台的代碼，才讓黑客有機可乘。

而Fosco Marotto，正是公司的CTO。

不過目前，提交代碼已經被刪除。

但還是被有心人找出了當時的網站快照。

快照上顯示，代碼中存在明顯的低級錯誤，第23行中的“reject”和“filter”被刪除了。

這兩個API函數，原本用於攔截SQL注入漏洞的攻擊。

具體而言，就是當SQL指令傳送到後端數據庫服務器時，確保其中的惡意命令已經被清除。

但他們沒有採取這種做法，而是在Rails函數中，添加了一個包含“find_by_sql”方法的調用，導致查詢字符串中的輸入未經過濾，而被直接接受。（Rails是一個網站開發工具包）

一位Facebook的前產品工程師Dmitry Borodaenko表示：

如果對SQL數據庫有任何了解的話，就應該聽說過SQL注入攻擊。

雖然現在還不能百分百確定是由這個漏洞所引起的，但也是極有可能的。

還有不少專家批評了公司事後刪除git commit的行為。

這種刪除違反了“分支源代碼必須公開透明”的條款。

諷刺的是，早在2012年，這位CTO還在StackOverFlow上警告過其他程序員別犯這樣的錯誤：

應該使用參數化查詢，防止被SQL注入攻擊。

因此就不免讓部分網友懷疑，這次他是故意洩露數據的。

CTO：生平第一次受到死亡威脅

事情還沒有公開報導的時候，Gab就立刻回應了此事，應該是因為一些記者收到了該公司的洩露數據。

2月26日，Gab CEO Andrew Torba就發表官方聲明，否認了這一入侵行為。

我們發現了這一漏洞，並在上週已經進行了修補，還將著手進行全面的安全審核。

並表示就個人信息而言，Gab從用戶那裡收集的信息非常少。因此一旦發生洩漏，對用戶的影響也會降至最低。

但這件事被ArsTechnica報導、事態更加嚴重之後，Gab選擇了與CTO站在一起一致對外。

CEO Andrew Torba連發兩條聲明，承認了官網被入侵這一事實。

他還表示公司正受到黑客的勒索，贖金為近500000美元的比特幣，並且此事已經向執法部門報告。

而當事人——CTO Fosco Marotto，也在HackerNews發表了個人聲明。

當中顯示“自己生平第一次受到了死亡威脅”，“目前沒有任何證據顯示，那次代碼提交與這次黑客入侵有任何直接聯繫”，“向ArsTechnica提供消息的那個人，跟我有個人恩怨”。

還給出了一些辯駁的理由：

我過去寫了很多年的SQL，當然清楚用戶輸入的重要性。我還曾用各種語言寫過很多用戶輸入的代碼。

我並不是一個Rails開發者，我對Rails和ActiveRecord是持否定態度的。

網友：CTO還自己寫代碼？

事件一出，不少網友直接將矛頭指向CTO：為什麼C級高管還要親自寫代碼？

有人認為，CTO應該有更重要的職責，比如戰略制定和決策，而不是關注細節，更不會親自寫代碼。

對此，也有人提出不同觀點：

這並不是通用法則，在不同的公司，CTO的工作內容可能會大不相同。

在Gab這樣的小型初創公司，CTO作為技術水準最高的人，親自寫代碼，並非是不可能的。即便不是親自寫代碼，也需要為項目的交付流程負責。

不過，讓黑客利用SQL注入攻擊，還發生在一位前Facebook工程師身上，這實在讓很多網友感到難以置信。

一位網友直言道：如果CTO審查後還出現這種錯誤，他就是個白痴，要么就是工程師們在欺騙白痴。

也有網友為他鳴不平

部分網友表示：任何人都可能犯菜鳥錯誤，這就是為什麼即使是老闆，也要進行代碼審查的原因。

曾在Facebook擔任高級軟件工程師的一名網友，對此一點都不覺得驚訝：“沒有聽說過快速行動並解決問題嗎？重點是代碼速度，而不是質量。”

也有網友認為，前Facebook工程師不會犯菜鳥編碼錯誤，帳戶可能是被盜了。

不過隨即被網友回复：“被盜也只是另一個新手錯誤。”

還有網友指出，Gab也許沒有靜態分析安全測試工具（SAST），要么就是故意忽略了系統反饋。

現有的任何一個代碼靜態分析工具都會告訴你，這樣編寫SQL是一個非常糟糕的做法。CI管道甚至會直接拒絕代碼，拒絕合併代碼。

也就是說，即使開發人員忽略了這個明顯的漏洞，系統本身也能阻止它。

毫無疑問的是，無論過程如何，作為CTO的Fosco都要為這次事件承擔責任。

CTO們請注意！

那麼問題來了：如何避免重蹈Fosco的覆轍？

這裡有一份5.6K星的免費清單。

幾乎關於CTO的一切，都能在裡面找到，簡直是CTO培養的保姆級指南。

不過這份指南，將重點針對初創公司和高速增長型企業的CTO和研發副總裁。

內容涵蓋了從錄用到管理、技術、營銷等方面。

大致包括：角色定位、錄用流程、管理方法、員工手冊、開發過程、軟件架構、技術學習、初創企業、產品、營銷，以及其他相關資源的鏈接。

好了，就剩最後一個問題了。

首先你得是一個CTO。（手動狗頭）