SQL（结构化查询语言）注入是一个众所周知的软件漏洞和安全漏洞，即使不是最著名的漏洞之一。尽管名声在外，如何防止SQL注入仍然是主要漏洞之一，并且攻击仍在继续增长。查找SQL注入根据OWASPTop10，注入漏洞（SQL注入是其中之一）是Web应用程序安全中的头号问题。SQL注入在CWETop25中排名第六。其他类型的安全漏洞示例包括：指令注入(CWE-77)操作系统命令注入(CWE-78)休眠注入(CWE-564)表达式语言注入(CWE-917)所有这些漏洞都有一个共同点。利用来自系统外部的数据、用户或文件输入或任何潜在危险的功能来利用它们。幸运的是，SQL注入可以通过工具进行静态和动态检测。但是，您永远无法确定是否抓住了它们。防止SQL注入也是降低这些漏洞的频率和影响的关键。包含漏洞检测和预防的成熟DevSecOps流程可能会捕获并防止这些类型的漏洞影响已发布的产品。什么是SQL？SQL是一种特定于领域的语言，旨在管理关系数据库。关系数据库将数据呈现为行和列中的表的集合。每行都有一个提供与其他表的关系的键。以下是表“user”的示例：与CWE中常见漏洞枚举相关的内存错误Top25SQL是关系数据库中管理、查询和操作数据的首选语言。它定义了数据库创建中的表和关系。对于大多数日常使用，开发人员将SQL用于“CRUD”——创建、读取、更新和删除数据。为什么可以使用SQL？常见的编程语言不包括对SQL的支持。通过数据库供应商提供的API访问数据库命令。在许多情况下，SQL命令作为字符串发送，API对其进行解释并将其应用于数据库。以下是一些简单的SQL查询：典型的SQL查询采用以下形式：Select(something)from(somewhere)(optionalcondition)要使用上表作为示例从姓氏“Smith”的行中检索电子邮件，请使用以下命令SQL语句：Selectemailfromuserwherelastname='Smith'输出以下内容：Smith1234@mail.comJohn.smith@mail.netSmith1234@mail.com使用Web表单（见下文）从用户那里获取输入是Web应用程序中的常见用例。用户在“名称”字段中输入的数据，例如，根据收到的输入形成SQL查询。考虑以下简单的Web表单：软件处理表单并为变量赋值，如下所示：StringformName=request.getParameter(Name);输入为“Name”的字符串用于使用该用户输入组成查询：StringmyQuery="selectmessagefromuserwhereemail='"+formName+"';"使用此构造的查询：Selectmessagefromuserwhereemail='Smith1234@mail.com';它的输出（以上表为例）如下：假设用户输入直接在字符串中使用，那么懂SQL语法的人可以很容易地操作它来生成SQL查询。考虑以下示例：使用上面相同的表单，某人在电子邮件字段中输入“Smith1234@mail.com”或“1”=“1”。相同的代码将组装以下SQL查询字符串：Selectmessagefromuserwhereemail='Smith1234@mail.com'or'1'='1';添加看似无害的东西，如“or1=1”会改变查询的逻辑，并可能通过返回名为“users”的表中的所有行来泄漏数据。在这种情况下，您会看到表中每个用户的消息。严重的隐私问题，以及某些司法管辖区或环境中可能存在的法律问题，例如GDPR、HIPAA或CCPA。上述查询以以下意外输出结束：HelloPassword1234HowareyouDon'ttellanyoneWassupSQL注入的工作原理SQL注入（和其他类型的注入漏洞）的基本要点是在SQL查询字符串中使用来自应用程序外部的未经检查的数据，例如用户Enter文本。CWE89的描述：“SQL命令中使用的特殊元素的不适当中和（SQL注入）”更准确地定义了以下内容：“如果在用户可控输入中没有充分删除或引用SQL语法，生成的SQL查询可能会导致这些输入将被解释为SQL而不是普通用户数据。这可用于更改查询逻辑以绕过安全检查，或插入其他修改后端数据库的语句，可能包括执行系统命令。CWE数据库中的相同条目(CWE89)提供了此攻击的另一个简单示例。假设应用程序代表用户“wiley”进行查询，并且用户以包含SQL指令的方式构造输入，例如：name';DELETEFROMitems;--如果此应用程序不对此输入执行任何有效性检查，则查询将构造如下：SELECT*FROMitemsWHEREowner='wiley'ANDitemname='name';DELETEFROMitems;--'如果攻击成功，它将删除表项中的所有数据，从而造成数据库损坏。任何有效的SQL命令都可以通过这种方式执行。这是一个写/修改攻击的示例，其目标是破坏数据库或插入不需要的信息。前面的例子（“or1=1”）是一个读攻击，其目标是数据泄露。许多数据库服务器的实现都接受分号作为命令分隔符，这使得这种SQL注入非常危险。尾随“--”表示文本的其余部分是注释，从而强制SQL解释器忽略尾随引号，否则会导致语法错误。有几种方法可以欺骗组合查询字符串。有时以开发人员无法想象的方式。防止SQL注入的缓解措施开发人员应实施多种缓解措施。首先，安全立场应该考虑所有来自应用程序之外的不受信任的数据。以下是典型的缓解策略：使用带有参数化查询的准备好的语句。使用存储过程。白名单输入验证。转义所有提供的输入。这些在SQL注入OWASP备忘单中有更详细的描述。测试SQL注入的典型安全方法是在集成软件运行时执行各种类型的安全测试，作为常规QA操作的一部分。不幸的是，功能测试不会尝试将漏洞插入用户输入字段，因为大多数测试人员并不认为自己是坏人。除了传统上他们没有时间或方向的事实。手动测试注入型漏洞也很困难，因为它需要尝试许多不同的输入组合。这是模糊测试或模糊测试开始的地方。它创建随机的、意外的和无效的数据作为被测应用程序的输入。模糊测试是渗透测试的一部分，因为目标是通过暴露的接口暴露安全漏洞。渗透测试渗透测试（以及扩展的模糊测试）是有益的，因为它可以发现整个过程中的安全问题并揭示重要的安全问题。但是，与所有动态测试一样，这完全取决于测试量、代码和API覆盖率，以全面测试所有可能的排列组合。渗透测试取决于功能测试的完整性，通常是在用户界面级别。因此，请务必使用API测试和SAST支持渗透测试，以确保您的工作彻底。API测试API测试通过消除对脆弱且耗时的UI测试的依赖，有助于将功能和安全测试移至左侧。API层是许多应用程序功能所在的地方，测试在这一层对变化更有弹性，并且更容易自动化和维护。API级渗透测试API级渗透测试可以使用ParasoftSOAtest等工具来暴露SQL注入，其中可以从执行应用程序业务逻辑的现有功能测试创建自动化模糊测试。ParasoftSOAtest与著名的渗透测试工具BurpSuite集成。当使用ParasoftSOAtest执行功能测试场景时，测试中定义的API调用与请求和响应流量一起被捕获。每次测试中的BurpSuite分析工具会将流量数据传递给BurpSuite应用程序的一个单独运行实例，该实例将使用自己的启发式算法根据它在流量数据中观察到的API参数来分析API。渗透测试。然后，BurpSuite分析工具将采取BurpSuite发现的任何错误，并将它们报告为SOAtest中与访问API的测试相关的错误。ParasoftSOAtest结果被报告到Parasoft的报告和分析仪表板中。用于其他报告功能。要了解有关此集成的更多信息，请参阅我们之前的渗透测试文章。有关使用Burp进行SQL注入的Portswigger的更多信息，请查看他们的文章。下面是与Burp集成如何工作的表示：将这种类型的渗透测试集成到您的CI/CD过程中是防御SQL注入和其他类型漏洞的重要部分。渗透和模糊测试无疑是DevSecOps中的一个重要过程，并且至关重要。然而，这引发了疑问。当测试检测到安全漏洞时会发生什么？当软件团队发现其大部分用户输入的处理不安全时会发生什么？它当然需要修复，但代价是什么？在开发后期发现严重的安全问题可能会导致严重的成本和延误。预防和检测是将安全操作进一步转移到更便宜、更容易修复的地方的关键。将SQL注入的检测和消除转移到左侧采用DevSecOps方法进行软件开发意味着将安全性集成到DevOps管道的各个方面。正如团队在SDLC早期推进代码分析和单元测试等质量流程一样，安全性也是如此。如果团队更广泛地采用这种方法，SQL注入可能会成为过去。攻击的增加意味着它还没有发生。不管怎样，让我们??概述一种尽早防止SQL注入的方法。与修补（和道歉！）已发布的应用程序相比，查找和修复潜在的SQL注入（和其他注入漏洞）可以节省大量时间。一次重大事件可能会使公司损失200,000美元或更多。小企业有很多事件。一次攻击可能会造成严重的财务压力，更不用说与泄露个人身份信息和保护个人身份信息相关的潜在监管问题了。下面概述的“检测和阻止”方法基于将SQL注入的风险缓解转移到开发的最早阶段，并通过静态代码分析检测来增强此功能。如何检测SQL注入检测SQL注入依赖于静态分析来发现源代码中的这些类型的漏洞。检测发生在开发人员的桌面和构建系统中。它可以包括现有的、遗留的和第三方代码。持续检测安全问题可确保发现以下所有问题：开发人员错过了IDE。存在于新检测预防方法之前的代码中。推荐的方法是信任但验证模型。安全分析发生在IDE级别，开发人员根据收到的报告做出实时决策。接下来，在构建级别进行验证。理想情况下，构建级别的目标不是查找错误。这是为了验证系统是否干净。例如，以Parasoft的演示应用程序Parabank为例。com.parasoft.parabank.dao.jdbc.internal中的StockDataInserter.java文件中可能存在SQL注入：...finalStringsql=sb.toString();rows=(nextId-lastId)/JdbcSequenceDao.OFFSET;totalRows+=rows;getJdbcTemplate().update(sql);...ParasoftJTest在构建时生成的报告如下：详情如下：CalltoadangerousmethodStockDataInserter.java(96):getJdbcTemplate().update(sql);***Tainteddata：SQL追溯到以前发现的源污染数据位置（来自应用程序外部的未经检查、未经验证的输入）：TaintingpointStockDataInserter.java(47):returngetJdbcTemplate().query(SQL,newResultSetExtractor
