惨遭敲诈后掩盖证据 收到死亡威胁
 具体而言，就是当 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 具体而言，就是当 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 （编辑：通化站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
