本文经AI新媒体量子位（公众号 ID: QbitAI）授权转载，转载请联系出处
量子位 报道 | 公众号 QbitAI 杨净 子豪 发自 凹非寺
堂堂一家公司的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。
（手动狗头）
参考链接：
[1]https://arstechnica.com/gadgets/2021/03/rookie-coding-mistake-prior-to-gab-hack-came-from-sites-cto/
[2]https://www.wired.com/story/gab-hack-data-breach-ddosecrets/
[3]https://news.ycombinator.com/item?id=26319649
[4]https://www.breitbart.com/tech/2020/11/18/free-speech-platform-gab-announces-facebook-vet-as-technical-chief/
[5]https://developers.slashdot.org/story/21/03/02/2230235/rookie-coding-mistake-prior-to-gab-hack-came-from-sites-cto
[6]https://news.gab.com/2021/02/26/alleged-data-breach-26-february-2021/
[7]https://news.gab.com/2021/03/01/gab-does-not-negotiate-with-criminal-demons/
[8]https://news.gab.com/2021/03/03/an-update-on-the-gab-breach/
Github资源地址：
