CTO寫程式碼弄出低級BUG：慘遭敲詐後掩蓋證據 收到死亡威脅
堂堂一家公司的CTO，到底能水到什麼程度？
因為一個低級錯誤，70GB大小的資訊數據被泄露，公司還被黑客敲詐了50萬美元。
而被發現後，他為了隱藏證據，竟還刪掉了程式碼…
這就是最近在一個社交媒體網站Gab上發生的真實事件。
上周末，黑客通過SQL注入漏洞入侵他們的官網，並竊取了15000位用戶的數據。
後經媒體調查發現，關鍵漏洞竟是由該公司的CTO造成的。
而這位CTO是一位入職不到半年，但有著23年開發經驗的工程師。
其前東家更是名牌「大廠」——Facebook。
於是就有網友質疑，這是公司眼瞎了？還是CTO太水了？
大廠「畢業」CTO，犯下致命低級錯誤
而事件的起因，是一位黑客利用SQL注入漏洞入侵了公司後台，竊取了數據。
這其中包含用戶公開、私人的帖子、哈希密碼以及私人資料，共涉及70000條資訊。
不光如此，黑客還將此事透露給了一個爆料網站DDoSecrets，與維基解密類似，從事披露黑客竊取的數據和機密資訊等工作。
在事件公開之前，該網站的記者還在社交網路上挑釁Gab的CEOAndrew 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 CEOAndrew Torba就發表官方聲明，否認了這一入侵行為。
我們發現了這一漏洞，並在上周已經進行了修補，還將著手進行全面的安全審核。
並表示就個人資訊而言，Gab從用戶那裡收集的資訊非常少。因此一旦發生泄漏，對用戶的影響也會降至最低。
但這件事被ArsTechnica報道、事態更加嚴重之後，Gab選擇了與CTO站在一起一致對外。
CEOAndrew Torba連發兩條聲明，承認了官網被入侵這一事實。
他還表示公司正受到黑客的勒索，贖金為近500000美元的比特幣，並且此事已經向執法部門報告。
而當事人——CTOFosco 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。（手動狗頭）
