生日快乐 SQL 注入，无法解决的错误

这篇文章的一个版本最初出现在 帮助网络安全。它已在此处更新和发布。

‍

如果你扮演的是亲身实践的网络安全角色——这个角色需要对代码有一定的熟悉程度——你很可能不得不一遍又一遍地考虑 SQL 注入...这是一个常见的漏洞，尽管在首次发现后的几周内就知道其补救措施相当简单，但它仍然困扰着我们的软件，如果在部署前未被发现，则为潜在的攻击者提供了很小的机会。

2020年12月13日是SQL注入的22岁生日，尽管这个漏洞已经过时了，可以喝了，但我们还是让它变得更好，而不是永远压制它。今年8月，Freepik公司透露他们有 成为 SQL 注入失误的受害者 这泄露了830万用户的账户。虽然其中许多人使用第三方登录名（例如谷歌、Facebook），但有几百万人泄露了未加密的密码和用户名。不幸的是，对于他们和其他许多人来说，这些事件的后果令人头疼，与用户群重建信任是一个长期的过程。

在我们用被认为是遗留问题来 “庆祝” 这一里程碑的同时，让我们稍微剖析一下。为什么它不断出现，为什么它仍然如此危险，多年来一直没有在OWASP前10名中脱颖而出，为什么它相对简单的修复没有进入软件开发的通用基准标准？

为什么 SQL 注入在 2021 年仍然有意义？

快速浏览一下最近一次备受瞩目的漏洞， 对 FireEye 的破坏性网络攻击，揭示了惊人的复杂程度：这是一次高度协调的民族国家袭击，使用了各种先进技术，这些技术似乎是为FireEye抢劫案量身定制的。FireEye首席执行官凯文·曼迪亚在一份声明中说：

”攻击者专门针对目标和目标量身定制了世界一流的能力 攻击 FireEye。他们在作战安全方面受过严格的训练，执行时纪律严明... 他们使用了我们或我们的合作伙伴过去从未见过的新颖技术组合。”

对于任何首席信息安全官来说，这都是噩梦般的燃料，如果FireEye可能发生这样的事情，那么它可以透视许多企业到底有多脆弱。

... 除了，是偶数 更差的 普通组织的新闻。FireEye是地球上最著名的网络安全公司之一，对他们的成功攻击需要策划级别的骗子将他们所拥有的一切投入到协调一致的大规模执行中。对于许多公司而言，利用一个简单的漏洞可能发生利润丰厚的数据泄露事件，而且完全不需要策划者。SQL 注入是后者的一个常见例子，想要在暗网上快速赚钱的脚本小伙子们仍在利用 SQL 注入。

2020 年 5 月， 一名男子被控犯有信用卡贩运和黑客罪，当时他被发现在数字媒体中存储了数十万个有效的信用卡号。他使用SQL注入技术将它们全部收集，该行动危及了许多公司和数百万客户。

作为一个行业，我们 是 一直在改进，但是 SQL 注入仍然是一个重大威胁，其影响远远超过传统或未修补的系统。

为什么开发人员要让它保持活力（以及为什么这不是他们的错）

我们一直说SQL注入很容易修复，编写代码时应该完全不引入它。像大多数事情一样，只有当你被教导如何正确地做时，这才是容易的。

这是软件开发过程中轮子开始摆动的地方。开发人员也在犯同样的错误，导致诸如 SQL 注入渗透到代码库之类的漏洞反复出现。但是，这不足为奇。大多数工程师在完成学位时没有学到太多关于安全编码的知识（如果有的话）。大多数在职培训都不充分，尤其是在他们不将安全视为业务优先事项的环境中。

我们没有给开发人员一个关心安全的理由，也没有给开发者一个开始提高安全意识的强大平台。糟糕的编码模式使像 SQL 注入这样的错误持续存在，我们需要更加重视开发人员的安全意识，让他们有时间编写更高标准的安全、高质量的代码。安全编码模式可能需要更长的时间来编写，但是花在那里的时间可以提高效率，这在流程的后期是非常宝贵的。

会有SQL注入葬礼吗？

葬礼的比喻有点病态，但实际上，如果让 SQL 注入永久停止，我们的敏感数据会更安全。但是，我非常有信心，在生日到来之前，我们会再庆祝几个生日，因为围绕预防性安全和对安全编码的重视的文化根本没有演变到足以开始关上棺材。

诸如 Rust 之类的更新、更具安全性的语言通过使用更安全的功能来帮助消除我们长期以来处理的一些错误，但是有大量的遗留软件、较旧的系统和库将继续处于使用状态，并且可能存在漏洞。

如果我们希望永久关闭 “简单” 的漏洞，那么在开发过程中，共同承担安全责任（你好，DevSecOps）至关重要。必须让开发人员从一开始就踏上旅程，并支持他们为创建更安全、更好的代码承担责任。

开发人员应该如何修复代码中的 SQL 注入错误？

我们整理了一个 综合指南 适用于想要学习如何识别和修复 SQL 注入的开发人员。使用他们选择的编程语言（甚至是 COBOL！）完成游戏化挑战，这提供了一些很好的基础学习，可以帮助每个开发人员创建更安全、更高质量的代码。