告诉你2022年怎么防止sql注入攻击

防止 SQL 注入攻击的第一步是确定哪些应用程序(如果有)易受攻击。事实上，通过SQL数据库实例可以看出，任何与 SQL 数据库交互的网站都存在风险。我们深入探讨了 SQL 注入漏洞的自动检测类型、检测工具的作用以及专门检测此类攻击的供应商。

自我强加的攻击和检测类型

对于检测SQL 注入漏洞，行业建议是亲自对您的应用程序或网站发起攻击。SQL 及其变体可能很棘手，但攻击者非常了解如何构建可以破坏数据库的代码片段。有了可用的自动检测工具，漏洞测试再简单不过了。

测试 SQL 注入漏洞

有几种免费或商业渗透工具可供您的组织确定您的 SQL 注入漏洞位置。

通常，这些工具首先会探测您的站点以确定正在使用的数据库类型。有了这些知识，程序就可以构建查询来检查数据库的特征。由于最终用户几乎不需要 SQL 专业知识，检测工具就可以从目标中提取字段、表格，有时甚至是完整的数据转储。

也许最重要的是，提供的许多工具都包含错误修复功能，可以帮助消除一些已发现的漏洞。因为许多强大的 SQL 注入工具都是开源的，所以您的组织必须在陌生人之前测试您的应用程序。

使用 SQLi 检测工具

一些网络安全供应商和开源开发人员提供自动 SQL 注入工具来识别潜在漏洞。对于开源检测工具，SQLMap和jSQL仍然是最受欢迎的两个工具，其他工具包括：

烧烤SQL

盲目 SQL 位移

百思奇

该死的小型 SQLi 扫描器(DSSS)

爆炸

利维坦

NoSQL映射

暴君SQL

白寡妇

防止 SQL 注入攻击的 18 个步骤

尽管 SQL 注入攻击仍然是对 Web 管理员最危险的威胁，但好消息是网站所有者可以采取很多措施来减轻这种危险。

您可以采取以下 18 个步骤来显着降低成为 SQL 注入攻击受害者的风险：

1. 验证用户输入

防止 SQL 注入攻击的常见第一步是验证用户输入。首先，识别必要的 SQL 语句，并为所有有效的 SQL 语句建立白名单，将未验证的语句排除在查询之外。此过程称为输入验证或查询重新设计。

此外，您应该根据上下文为用户数据配置输入。例如，可以过滤电子邮件地址的输入字段以仅允许电子邮件地址中的字符，例如必需的“@”字符。类似地，电话号码和社会安全号码应该只被过滤以允许每个号码的特定位数。

虽然此操作本身并不能阻止 SQLi 攻击者，但它为 SQL 注入攻击的常见事实调查策略增加了障碍。

2. 通过限制特殊字符来清理数据

防范 SQL 注入攻击的另一个组成部分是缓解不充分的数据清理。因为 SQLi 攻击者可以使用独特的字符序列来利用数据库，所以清理数据以不允许字符串连接是至关重要的。

一种方法是将用户输入配置为一个函数，例如 MySQL 的 mysql_real_escape_string()。这样做可以确保任何危险字符(例如单引号' )不会 作为指令传递给 SQL 查询。避免这些未经身份验证的查询的主要方法是使用准备好的语句。

3.强制执行准备好的语句和参数化

遗憾的是，输入验证和数据清理并不是万能的。关键组织还使用带有参数化查询的准备好的语句(也称为变量绑定)来编写所有数据库查询。通过定义与查询或参数化相关的所有 SQL 代码，您可以区分用户输入和代码。

虽然动态 SQL 作为一种编码技术可以提供更灵活的应用程序开发，但它也可能意味着 SQLi 漏洞作为可接受的代码指令。通过坚持使用标准 SQL，数据库会将输入的恶意 SQL 语句视为数据，而不是潜在的命令。

4. 在数据库中使用存储过程

与参数化类似，使用存储过程也需要绑定变量。与缓解 SQLi 的准备好的语句方法不同，存储过程驻留在数据库中并从 Web 应用程序调用。如果使用动态 SQL 生成，存储过程也不能避免漏洞。

像OWASP这样的组织说只有一种参数化方法是必要的，但是这两种方法都不足以实现最佳安全性。制作参数化查询应该结合我们的其他建议来完成。

5.积极管理补丁和更新

可使用 SQL 注入利用的应用程序和数据库中的漏洞会定期被发现并公开识别。与许多网络安全威胁一样，至关重要的组织必须及时了解最新消息，并尽快应用补丁和更新。就 SQLi 而言，这意味着保持所有 Web 应用程序软件组件(包括数据库服务器软件、框架、库、插件和 Web 服务器软件)是最新的。

如果您的组织难以始终如一地修补和更新程序，那么补丁管理解决方案可能值得投资。

6.提高虚拟或物理防火墙

我们强烈建议使用基于软件或设备的Web 应用程序防火墙 (WAF)来帮助过滤掉恶意数据。

今天的防火墙，包括NGFW和FWaaS产品，既有一套全面的默认规则，也可以根据需要轻松更改配置。如果补丁或更新尚未发布，WAF 可以派上用场。

一个流行的示例是免费的开源模块ModSecurity，可用于 Apache、Microsoft IIS 和 nginx Web 服务器。ModSecurity 提供了一套复杂且不断发展的规则来过滤具有潜在危险的 Web 请求。它的 SQL 注入防御可以捕获大多数通过 Web 渠道偷偷执行 SQL 的尝试。

7. 强化你的操作系统和应用程序

此步骤超越了减轻 SQL 注入攻击，确保您的整个物理和虚拟框架有意地工作。随着2020 年供应链妥协的重大消息，许多人正在寻求 NIST 和其他行业标准安全检查表来强化操作系统和应用程序。

采用应用程序供应商安全指南可以增强组织的防御态势，并有助于识别和禁用不必要的应用程序和服务器。

8. 减少你的攻击面

在网络安全中，攻击面是指攻击者的一系列潜在入口点。因此，在 SQLi 攻击的上下文中，这意味着处理您不需要 的任何数据库功能或进一步保护它们。

一个这样的例子是 Microsoft SQL Server 中的xp_cmdshell扩展存储过程。此过程可以生成一个 Windows 命令外壳并传递一个字符串以供执行。由于xp_cmdshell生成的Windows进程与SQL Server服务账户具有相同的安全权限，攻击者可以造成严重破坏。

9.建立适当的权限和严格的访问

鉴于 SQL 数据库对组织的强大功能，必须使用严格的规则执行最小权限访问策略。如果一个网站只需要对数据库使用 SELECT 语句，那么它就没有理由拥有额外的 INSERT、UPDATE 或 DELETE 权限。

此外，您的数据库应该只在必要时以管理员级别的权限访问，不要介意授予其他人访问权限。使用受限访问帐户对于一般活动要安全得多，并且如果权限较低的凭据遭到破坏，最终会限制攻击者的访问权限。

10.限制读取访问

连接到 SQL 注入保护的最小权限原则是配置对数据库的读取访问。如果您的组织只需要使用读取权限的活跃用户，那无疑更容易采用。尽管如此，这个添加的步骤对于阻止攻击者更改存储的信息是必不可少的。

11. 加密：保守秘密

最好假设联网应用程序不安全。因此，加密和散列密码、机密数据和连接字符串至关重要。

如今，加密几乎被普遍用作数据保护技术，这是有充分理由的。如果没有适当的加密和散列策略，入侵者可能会轻易看到敏感信息。虽然只是安全清单的一部分，微软指出加密“将保护数据的问题转化为保护密钥的问题。”

12. 拒绝扩展 URL

SQLi 攻击者的另一种策略是发送过长的 URL，导致服务器无法记录完整的请求。2013 年，eSecurityPlanet报告了攻击者如何通过向用户发送会触发基于堆栈的缓冲区溢出的长 URL 来利用 Foxit。

作为另一个示例，Microsoft IIS 是为处理超过 4096 字节长的请求而构建的。但是，Web 服务器软件无法将请求的内容放入日志文件中。然后，攻击者可以在执行查询时不被发现。为避免这种情况，请为 URL 设置 2048 字节的限制。

13. 不要在错误消息中泄露超过必要的信息

SQL 注入攻击者可以从错误消息中了解有关数据库体系结构的大量信息，从而确保它们只显示最少的信息。使用“RemoteOnly”customErrors 模式(或等效模式)可以在本地计算机上显示详细的错误消息，同时确保外部攻击者只知道他或她的操作导致了未处理的错误。此步骤对于保护组织的内部数据库结构、表名或帐户名至关重要。

14.没有共享数据库或用户帐户

多个网站或应用程序共享数据库可能会导致灾难。对于有权访问各种 Web 应用程序的用户帐户也是如此。这种共享访问可能会为管理组织或管理员提供灵活性，但它也不必要地带来了更大的风险。

理想情况下，任何链接服务器都对目标服务器具有最小访问权限，并且只能访问关键任务数据。链接服务器应该具有与目标服务器上任何进程不同的登录名。

15. 执行帐户和密码策略的最佳实践

虽然这可能不言而喻，但组织必须遵循最佳帐户和密码策略以确保万无一失的安全性。默认密码和内置密码应在收到后和使用前更改，并定期更新密码。长度和字符复杂性合适的密码对于所有 SQL Server 管理员、用户和计算机帐户都是必不可少的。

16. SQL语句的持续监控

组织或第三方供应商应持续监控应用程序的所有连接数据库的应用程序的 SQL 数据库语句，包括记录所有数据库帐户、准备好的语句和存储过程。通过了解 SQL 语句的运行方式，可以更轻松地识别流氓 SQL 语句和漏洞。在此持续审查中，管理员可以删除和禁用不必要的帐户、准备好的报表和存储过程。

利用机器学习和行为分析的监控工具(如PAM和SIEM)可以成为网络安全的绝佳附加组件。

17. 定期进行审计和渗透测试

定期审核您的数据库和应用程序安全性变得越来越必要，包括审核日志中的可疑活动、组和角色成员资格特权以及可变绑定条款。

与审计恶意行为一样重要的是进行渗透测试，以了解您的防御措施如何应对一系列潜在攻击，包括 SQLi。大多数渗透测试公司都能发现诸如跨站点脚本、停用软件、未修补漏洞、注入和不安全密码等威胁。

18. 代码开发和购买更好的软件

在广阔的软件解决方案市场中，肯定存在解决方案的层次结构。虽然企业组织可以支付昂贵的第三方解决方案的成本，甚至可以在内部进一步开发软件，但较小的组织理所当然地使用较少的或考虑免费的开源工具。

但是，在很大程度上，供应商代码编写者最终要为客户的自定义应用程序中的缺陷负责。考虑供应商的组织必须热衷于此，并确保合同条款反映这种代码审查职责。

如何阻止 SQL 注入?

就像零信任安全的精神一样，减轻 SQL 注入攻击意味着担心所有用户提交的数据都可能是恶意的。我们鼓励您考虑我们的建议并制定计划来审查您的 SQL 安全状况， 而不是让攻击利用SQL 漏洞。

虽然输入验证、清理、准备好的语句和存储过程等最初的数据库安全步骤是必不可少的，但它们只是底线。为了最大程度地防止 SQLi 攻击，组织还需要考虑以下解决方案：

特权访问管理 (PAM)

渗透测试

安全信息和事件管理(SIEM)

下一代防火墙(NGFW)

网络访问控制(NAC)

入侵检测和预防(IDPS)

威胁情报

用户和实体行为分析(UEBA)