这篇文章的一个版本最初出现在 帮助网络安全.它已被更新并在此转发。

‍

如果你是从事网络安全工作的人--一个需要熟悉代码的人--你很有可能不得不考虑SQL注入的问题......一次又一次的。这是一个常见的漏洞，尽管在第一次发现后的几周内就知道其相当简单的补救措施，但它仍然困扰着我们的软件，如果在部署前没有被发现，就会给潜在的攻击者提供一个小小的机会。

2020年12月13日是SQL注入的22岁生日，尽管这个漏洞已经老得可以喝酒了，但我们还是让它得寸进尺，而不是把它永远压下去。今年8月，Freepik公司披露，他们成为一个SQL注入错误的受害者，该错误损害了830万用户的账户。虽然他们中的一些人利用了第三方登录（如谷歌、Facebook），但有几百万人的未加密密码与他们的用户名一起被暴露。可悲的是，对于他们和其他许多人来说，这些事件的后果是一个巨大的头疼问题，与用户群重建信任是一个长期过程。

当我们用一个被认为是遗留的问题来 "庆祝 "这个里程碑的时候，让我们来剖析一下它。为什么它不断出现，为什么它仍然如此危险，多年来没有离开OWASP排名前十的位置，为什么它相对简单的修复方法没有进入软件开发的一般基准标准？

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

只要看一眼最近引人注目的漏洞，即对FireEye的破坏性网络攻击，就会发现其复杂程度令人震惊：这是一次高度协调的民族国家攻击，利用各种先进技术，似乎是为FireEye抢劫案定制的。FireEye首席执行官Kevin Mandia在一份声明中说。

"攻击者专门为目标和 攻击 FireEye定制了他们的世界级能力 。他们在操作安全方面训练有素，执行起来纪律严明，重点突出......他们使用了我们或我们的合作伙伴过去没有见过的新颖技术组合。”

这对任何CISO来说都是噩梦，如果像这样的事情发生在FireEye身上，那就说明许多企业真的很脆弱。

......只不过，对于普通组织来说，这是个更糟糕的消息。FireEye是地球上最著名的网络安全公司之一，对他们的成功攻击需要大师级的骗子在协调、大规模的执行中倾尽全力。对于许多公司来说，通过利用一个简单的错误，一个有利可图的数据泄露可能是可能的，而且相当快，完全不需要主谋。而SQL注入是后者的一个常见例子，仍然被希望在暗网上赚取快钱的脚本小子们所利用。

2020年5月，一名男子被指控犯有贩卖信用卡和黑客行为，当时他被发现拥有存储数十万个有效信用卡号码的数字媒体。他使用SQL注入技术获取了所有这些数字，在一次行动中，许多公司和他们的数百万客户受到影响。

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

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

我们一直在说，SQL注入是很容易解决的，代码应该写得很好，以避免引入它。就像大多数事情一样，只有当你被教导如何正确操作时，它才会变得简单。

这就是软件开发过程中车轮开始晃动的地方。开发人员正在犯同样的错误，导致像SQL注入这样的漏洞反复出现在代码库中。然而，这不应该是一个惊喜。大多数工程师在完成他们的学位时并没有学到很多关于安全编码的知识，如果有的话。大多数在职培训是不充分的，特别是在一个环境中，安全没有被视为他们角色的业务优先事项。

我们没有给开发者一个关心安全的理由，也没有一个强大的平台让他们开始变得更有安全意识。不良的编码习惯使像SQL注入这样的错误继续存在，我们需要更加强调开发人员的安全意识，并给他们时间来编写更高标准的安全、高质量的代码。安全的编码模式可能需要更长的时间来编写，但花在这里的时间创造了效率，在以后的过程中是非常宝贵的。

会不会有一个SQL注入的葬礼？

葬礼的比喻有点病态，但实际上，如果SQL注入被永远埋葬，我们的敏感数据会更安全。然而，我很有信心，在这之前我们还会庆祝几个生日，因为围绕预防性安全和强调安全编码的文化还没有发展到足以开始钉住棺材的程度。

像Rust这样较新的、更安全的语言，通过利用更安全的函数，正在帮助消除一些我们已经处理了很长时间的bug，但有大量的遗留软件、旧系统和库将继续保持使用状态，并有潜在的脆弱性。

如果我们想看到 "容易 "的漏洞被永久关闭，在开发过程中共同承担安全责任（你好，DevSecOps）将是至关重要的。开发人员必须从一开始就参与到这个过程中来，并支持他们在创建更安全、更好的代码中承担起责任。

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

我们为那些想学习如何识别和修复SQL注入的开发者准备了一份全面的指南。在他们选择的编程语言（甚至是COBOL！）中完成了一个游戏化的挑战，这提供了一些伟大的基础学习，将帮助每个开发人员创建更安全、更高质量的代码。