SQL 注入生日快乐，这个永远无法被彻底消灭的漏洞

本文最初发表于 Help Net Security。现经更新后在此转载。

‍

如果你从事的是需要接触代码的实操型网络安全工作，那么你很可能已经无数次地思考过 SQL 注入问题。这是一个常见的漏洞，尽管在首次发现后的几周内我们就掌握了简单的修复方法，但它依然在困扰着我们的软件。如果未能在部署前检测到，它就会为潜在的攻击者留下可乘之机。

2020 年 12 月 13 日是 SQL 注入漏洞的 22 岁生日。尽管它早已“成年”，但我们却任由其肆虐，而非将其彻底根除。今年 8 月，Freepik 公司披露他们 因 SQL 注入漏洞遭受攻击，导致 830 万用户账户受损。虽然其中许多用户使用了第三方登录（如 Google、Facebook），但仍有数百万用户的用户名和未加密密码被泄露。对于他们以及在此过程中受影响的许多人来说，这些事件带来的后果令人头疼，而重建用户信任更是一个漫长的过程。

在我们“庆祝”这个遗留问题迎来里程碑的同时，让我们剖析一下：为什么它总是反复出现？为什么它如此危险，以至于多年来一直稳居 OWASP 十大漏洞榜首？为什么它那相对简单的修复方法始终无法成为软件开发的通用基准标准？

为什么 SQL 注入在 2021 年依然是个问题？

回顾最近的一起高调安全事件——针对 FireEye 的毁灭性网络攻击，我们可以看到其复杂程度令人咋舌：这是一次高度协调的国家级攻击，利用了多种看似专为 FireEye 量身定制的高级技术。FireEye 首席执行官 Kevin Mandia 在声明中表示：

“攻击者利用其世界级的技术能力，专门针对并攻击了 FireEye。他们受过严格的操作安全训练，执行过程纪律严明、目标明确……他们使用了一套我们及合作伙伴此前从未见过的创新技术组合。”

这对任何首席信息安全官（CISO）来说都是一场噩梦。如果连 FireEye 都会遭遇此类攻击，那么这足以让我们看清许多企业实际上是多么脆弱。

……但对于普通组织而言，情况甚至更糟。FireEye 是全球最著名的网络安全公司之一，针对他们的成功攻击是由顶级黑客精心策划、大规模执行的结果。而对于许多公司来说，利用一个简单的漏洞就能快速实现有利可图的数据窃取，根本不需要什么顶级黑客。SQL 注入就是后者的典型例子，至今仍被那些想在暗网上赚快钱的“脚本小子”所利用。

2020 年 5 月，一名男子因信用卡贩卖和黑客攻击罪名被起诉，警方在他持有的数字媒体中发现了数十万个有效的信用卡号码。他利用 SQL 注入技术窃取了这些信息，其行动波及多家公司及其数百万客户。

作为整个行业，我们确实在不断进步，但 SQL 注入仍然是一个重大威胁，其影响范围远不止于遗留系统或未打补丁的系统。

为什么开发人员让它“长存”（以及为什么这并非他们的错）

我们一直说 SQL 注入很容易修复，编写代码时就应该避免引入它。但像大多数事情一样，只有在有人教你如何正确操作时，它才显得简单。

这就是软件开发流程中出现偏差的地方。开发人员不断重复同样的错误，导致 SQL 注入等漏洞反复潜入代码库。然而，这并不令人意外。大多数工程师在获得学位时，几乎没有学过安全编码知识。大多数在职培训也差强人意，尤其是在那些不将安全视为业务优先事项的环境中。

我们既没有给开发人员关心安全的理由，也没有提供让他们提升安全意识的有力平台。糟糕的编码模式让 SQL 注入等漏洞得以存续。我们需要更加重视开发人员的安全意识，并给予他们时间去编写更高标准、高质量的安全代码。编写安全代码模式可能需要更长的时间，但由此带来的效率提升在后续流程中是无价的。

SQL 注入会有被彻底终结的一天吗？

用葬礼来比喻可能有点病态，但说实话，如果能彻底终结 SQL 注入，我们的敏感数据会更安全。不过，我非常确信在这一天到来之前，我们还会为它庆祝好几个生日，因为预防性安全文化和对安全编码的重视程度，还远未进化到足以将它彻底埋葬的地步。

Rust 等更新、安全性更强的编程语言通过使用更安全的函数，正在帮助消除我们长期以来一直面临的一些漏洞。然而，仍有海量的遗留软件、旧系统和代码库将继续使用，并可能存在潜在的安全风险。

如果我们希望彻底杜绝那些“简单”的漏洞，开发过程中共同承担的安全责任（即 DevSecOps）将至关重要。必须让开发人员从一开始就参与其中，并支持他们为编写更安全、更优质的代码承担起应有的责任。

开发人员应如何着手修复代码中的 SQL 注入漏洞？

我们为想要学习如何识别和修复 SQL 注入的开发人员编写了一份 综合指南。该指南包含使用多种编程语言（甚至包括 COBOL！）进行的游戏化挑战，旨在提供扎实的基础学习，帮助每位开发人员编写出更安全、更高质量的代码。