共计 1301 个字符，预计需要花费 4 分钟才能阅读完成。
| 导读 | 即使是大型科技公司，依然会被软件和 Web 漏洞所困扰，其中 SQL 注入是常见也是最危险的漏洞之一。以下是降低 SQL 注入漏洞风险的三大方法。 |
即使是大型科技公司，依然会被软件和 Web 漏洞所困扰，其中 SQL 注入是常见也是最危险的漏洞之一。在 MITRE 近日发布的过去两年中最常见和最危险的 25 个软件漏洞列表 (见下图) 中，SQL 注入漏洞的排名高居第六：
以下是降低 SQL 注入漏洞风险的三大方法：
首先确保客户端输入验证不是唯一的防线。这种验证是改善用户体验的好工具，但它不能作为一种安全机制。因为，通过更改浏览器中加载的 JavaScript 代码，或使用导致 SQL 注入的参数对客户端 - 服务器架构中的后端进行基本 HTTP 调用，可以轻松删除客户端验证。
所以开发人员应该在服务器端进行验证，且尽可能靠近源; 开发人员还应该仔细考虑数据库用户权限，所有 SQL 注入攻击都是有害的，但有些攻击比其他攻击更危险：访问用户信息是一回事，更改或删除信息是另一回事，应考虑特定应用程序是否真的有必要能够截断或删除数据。
除了不允许每个应用程序自由支配一个数据库之外，一个应用程序只有一个数据库用户也是不明智的。应创建多个数据库用户，并将其连接到特定的应用程序中进行角色分工，这可以防止攻击者快速接管整个数据库。
提升软件安全性的一个关键方法是使用预设语句和查询参数化。预设语句能够限制可输入的 SQL 语句：开发人员创建一个带有占位符的基本查询，然后用户给定的参数可以安全地附加到这些占位符上。在使用预设语句和参数化查询时，数据库会首先根据带有占位符的查询字符串构建查询执行计划，然后将 (不可信的) 参数发送到数据库。
使用存储过程时，参数化也很重要。就像在应用程序中创建的任何 SQL 查询一样，存储过程也可能被恶意注入。因此，与 SQL 查询一样，开发人员应该在他们的存储过程中参数化查询，而不是连接参数，以防止注入。
但是，在某些情况下，预设语句不可用。比如如果某种语言不支持预设语句，或者较旧的数据库不允许开发人员将用户输入作为参数提供，此时输入验证是一个可接受的替代方案。但团队应该确保，输入验证依赖的是一个使用维护良好的库或创建一个规则来描述所有允许的模式，例如，使用正则表达式。当然，即使预设语句可用，输入验证也是必须的。
除了参数化和输入验证之外，开发人员还应考虑使用对象关系映射 (ORM) 层来防止 SQL 注入。将数据从数据库转换为对象，反之亦然，从而减少了显式 SQL 查询和 SQL 注入攻击的风险。但是需要注意的是，如果使用错误、过时的 Sequelize 或 Hibernate 版本，ORM 库中仍然会产生漏洞，因此开发人员必须保持警惕。
最终，无论部署什么安全策略，都必须有一个严格的审查系统来审查代码并标记所有漏洞。代码审查和结对编程确实允许这样做，但手动审查过程总是存在误差。为了获得最高级别的安全性，开发人员应该寻找专门设计的扫描工具来自动检查 SQL 注入漏洞并提醒他们代码中的所有弱点。
