在Colonial Pipeline网络攻击事件和其他备受瞩目的案例之后，IT团队可能正在努力加强他们的端点保护。但开发者社区的人知道，安全漏洞并不是从这里开始和结束的。如果是不恰当地编写代码或安全性不足，也就意味着在为未来的网络攻击编写代码。

对于科技公司来说，Web漏洞是一个影响甚大的问题。它们涵盖了许多不同的编码问题，在上述攻击事件中包括一个非常具体的类型。

SQL注入是最危险和最常见的漏洞之一，但幸运的是，开发人员可以遵循一些最佳实践来确保安全防护的缝隙相对较小。

首先是确保客户端输入验证不是唯一的防线。这种验证对于改进用户体验来说是一个很好的工具，但它不能作为一种安全机制。

通过更改浏览器中加载的JavaScript代码或使用导致SQL注入的参数对客户端-服务器架构中的后端进行基本HTTP调用，可以很容易地删除客户端验证。开发人员应该将客户端发送的所有信息视为潜在的有害信息，因此应该在服务器端进行验证，理想情况下应该尽可能接近源。

开发人员还应该仔细考虑数据库用户权限。所有SQL注入攻击都是有害的，但有些攻击比其他的更有害:访问用户信息是一回事，而修改或删除用户信息则是另一回事。

为了最小化SQL注入的影响，开发人员应该对应用程序在数据库上的权限进行战略性的考虑。一个特定的应用程序真的需要读取、写入和更新所有数据库的能力吗?它是否必须能够截断或删除表?

除了不允许每个应用程序自由支配一个数据库之外，一个应用程序只有一个数据库用户也是不明智的。创建多个数据库用户并将他们连接到特定的应用程序角色的工作方式与防火门的工作方式相同：它可以防止攻击者快速接管整个数据库。

参数是很好的防御

开发人员保护自己的一个关键方法是使用预处理语句和查询参数化。许多语言都有内置的特性来帮助防止SQL注入，因此在编写SQL查询时，可以使用准备好的语句来编译查询。

准备好的语句可用于执行查询参数化，这限制了可以输入的SQL语句：开发人员创建一个带有占位符的基本查询，然后用户给定的参数可以安全地附加到这些占位符上。当使用预处理语句和参数化查询时，数据库将首先基于带有占位符的查询字符串构建查询执行计划，然后将(不受信任的)参数发送给数据库。

由于已经创建了查询计划，因此参数不再影响此操作，并且完全阻止了注入。因此，带有查询参数化的预处理语句是对SQL注入的很好防御措施。

在使用存储过程时，参数化也是非常重要的。许多人认为使用存储过程是防止SQL注入的好方法，但情况并非总是如此。就像在应用程序中创建的任何SQL查询一样，存储过程也可能被恶意注入。因此，与SQL查询一样，开发人员应该在存储过程中参数化查询，而不是连接参数，以防止注入。

然而，在某些情况下，预处理语句是不可用的。如果某种语言不支持预处理语句，或者较旧的数据库不允许开发人员将用户输入作为参数提供，那么输入验证是一种可接受的替代方法。

团队应该确保输入验证依赖于允许列表而不是阻止列表——使用维护良好的库或创建一个规则来描述所有允许的模式，例如，使用正则表达式。当然，即使准备好的语句可用，输入验证也是必须的。

多层次安全，严格检查

除了参数化和输入验证之外，开发人员还应考虑使用对象关系映射( ORM ) 层来防止注入。这将数据从数据库转换为对象，反之亦然，从而减少了显式SQL查询降低SQL注入攻击的风险。但是需要注意的是，如果使用错误或过时的Sequelize或 Hibernate版本，ORM库中仍然会出现漏洞，因此开发人员必须保持警惕。

最终，也是需要重视的一点是，无论部署什么安全策略，都必须有一个严格的审查系统来审查代码并标记发现的漏洞。为了确保较高的安全性，开发人员应该使用安全可控的专业静态代码扫描工具来自动检查SQL注入漏洞并显示出代码中的缺陷问题。

SQL注入攻击是一种危险的网络威胁，好在可以防御。通过严格的静态代码检测查找漏洞并修复，可以有效提高代码质量从而加强软件安全，进而阻止注入攻击。随着网络犯罪与数字化同步增长，开发人员将安全性写入代码的核心观念，比以往任何时候都更加重要。

参读链接：