SQL(结构化查询语言)注入是众所周知的软件弱点和安全漏洞，如果没有，也是最著名的漏洞之一。虽然很有名，但如何防止？SQL注入仍然是主要漏洞之一，攻击继续增长。
查找SQL注入
根据OWASP Top 10注入漏洞(包括SQL注入是其中之一)Web应用程序安全的头号问题。SQL注入在CWE Top 25排名第六。其他类型的安全漏洞包括：- 指令注入(CWE-77)
- 注入操作系统命令(CWE-78)
- 冬眠注射(CWE-564)
- 注入表达语言(CWE-917)
幸运的是，SQL注入可以通过工具静态和动态检测到。然而，你永远无法确定它们是否都被抓住了。SQL注入也是减少这些漏洞频率和影响的关键。结合成熟的漏洞检测和预防功能DevSecOps这些类型的漏洞很可能止这些类型的漏洞进入已发布的产品。
什么是SQL?
SQL它是一种特定于域的语言，旨在管理关系数据库。关系数据库将数据显示为行和列中表的集合。每行都有一个提供与其他表格关系的键。“user”的示例：
与CWE Top 25中常见的漏洞枚举与内存错误有关
SQL它是管理、查询和处理关系数据库中数据的首选语言。它定义了数据库创建中的表和关系。对于大多数日常使用，开发人员将SQL用于“CRUD”—创建、读取、更新和删除数据。为什么SQL可利用?
不包括一般编程语言SQL的支持。通过数据库供应商提供的API访问数据库命令。SQL命令以字符串的形式发送，API将字符串解释并应用于数据库。以下是一些简单的SQL查询：
典型的SQL以下形式查询：
软件处理表并将值分配给变量，如下所示：
使用上同的表格，有人在电子邮件字段中输入“Smith1234@mail.com”或“1” =“1”。
下面将组装相同的代码SQL查询字符串：
以下意外输出结束：
SQL注入的工作方式
SQL注入(以及其他类型的注入漏洞)的基本要点是SQL查询字符串中使用来自应用程序外部的未经检查的数据，例如用户输入文本。CWE 89描述:“SQL不适当中和命令中使用的特殊元素(SQL注入)”更准确地定义以下内容：“未完全删除或引用用户可控输入SQL在语法的情况下，生成SQL查询可能会导致这些输入被解释为SQL而不是普通用户数据。这可用于更改查询逻辑以绕过安全性检查，或用于插入修改后端数据库的其他语句，可能包括执行系统命令。”
CWE数据库中的相同条目(CWE 89)为此攻击提供了另一个简单的例子。假设应用程序代表用户“wiley”查询并包含用户SQL例如：
许多数据库服务器的实现都接受分号作为命令分隔符，这使得这种情况SQL注射非常危险。“–”文本的其余部分是注释，迫使SQL解释器忽略了尾部的引号，否则会导致语法错误。查询字符串的方法有很多。有时是开发人员无法想象的。
防止SQL缓解注入
开发人员应采取几种缓解措施。首先，安全立场应考虑来自不可信应用程序的所有外部数据。以下是典型的缓解策略：- 将准备好的句子与参数查询一起使用。
- 使用存储过程。
- 输入白名单验证。
- 转换所有提供的输入。
测试SQL注入
一种典型的安全方法是在集成软件运行过程中执行各种类型的安全测试，作为常规质量检验操作的一部分。不幸的是，功能测试不会尝试将漏洞插入用户输入字段，因为大多数测试人员不认为他们是坏演员。
除了传统上他们没有时间或方向的事实。手动测试也很难注入类型漏洞，因为它需要尝试许多不同的输入组合。这是开始模糊测试或模糊测试的地方。它将创建随机、意外和无效的数据作为被测应用程序的输入。模糊测试是渗透测试的一部分，因为目标是通过公共界面披露安全漏洞。
渗透测试
渗透性测试（和扩展性模糊性测试）是有益的，因为它可以发现整个过程中的安全问题，并揭示重要的安全问题。然而，与所有动态测试一样，它完全取决于测试、代码和API覆盖的数量可以完全测试所有可能的排列和组合。渗透测试取决于功能测试的完整性，通常在用户界面级别进行。因此，请务必通过API测试和SAST支持渗透测试，确保你的工作彻底。
API测试
API通过消除脆弱和耗时的测试UI依赖测试有助于向左移动功能和安全性测试。API层是许多应用程序功能停留的地方，在这个级别更改时测试更有弹性，更容易自动化和维护。
API层次渗透试验
使用诸如Parasoft SOAtest可以执行此类工具API水平渗透试验暴露SQL在这些工具中，可以从现有的功能测试中创建自动模糊测试，从而行使应用程序的业务逻辑。Parasoft SOAtest以及著名的渗透测试工具Burp Suite集成在一起。
使用Parasoft SOAtest在执行功能测试方案时，捕获测试中定义的API呼叫、请求和响应流量。每次测试Burp Suite分析工具将流量数据传输到Burp Suite根据流量数据中观察到的应用程序的单独运行实例API参数，使用自己的启发方法API渗透试验。
然后，Burp Suite获得分析工具Burp Suite将发现的任何错误报告为SOAtest中与访问API与测试相关的错误。Parasoft SOAtest报告结果Parasoft报告和分析仪表板。其他报告功能。
有关此集成的更多信息，请参阅我们以前的渗透测试文章。Portswigger关于使用Burp进行SQL更多注入信息，请查看其文章。以下是与Burp集成工作模式的表示：
将这种类型的渗透测试集成到您身上CI/CD过程是防御SQL注入和其他类型漏洞的重要组成部分。
无疑是渗透和模糊测试DevSecOps这是一个重要的过程，也是至关重要的。然而，这提出了问题。
- 检测安全漏洞时会发生什么？
- 当软件团队发现大多数用户的输入处理不安全时，会发生什么？
- 当然需要修复，但是要付出什么代价呢？
将SQL检测和消除向左移动
采用软件开发DevSecOps方法意味着将安全集成到DevOps管道的各个方面。就像团队尽快在一样SDLC促进代码分析和单元测试等质量流程的安全性也是如此。如果团队更广泛地采用这种方法，则SQL注入可能已经成为过去。攻击的增加意味着它还没有发生。无论如何，让我们总结一种可以尽快预防的方法SQL注入方法。
与修发布的应用程序相比，搜索和修复潜在的应用程序SQL注入（和其他注入漏洞）可以节省很多时间。一个重大事件可能会损失20万美元或更多。小企业发生了许多事件。攻击会造成严重的财务压力，更不用说非法披露和保护个人身份信息的潜在监管了。
下面概述的“检测和阻止”方法基于将减轻SQL通过静态代码分析检测，将注入的风险转移到开发的最早阶段，以增强此功能。
如何检测SQL注入
检测SQL注入依靠静态分析在源代码中找到这些类型的漏洞。检测发生在开发人员的桌面和构建系统中。它可以包括现有的、旧的和第三方代码。
安全问题的连续检测可以保证以下问题的发现：
- 错过了开发人员IDE。
- 它存在于比你的新检测预防方法更早的代码中。
例如，以Parasoft演示应用程序Parabank为例。com.parasoft.parabank.dao.jdbc.internal中的StockDataInserter.java可能存在于文件中SQL注入：
详情如下：
事实上，开发人员应该验证应用程序外的任何数据，以确保它们符合预期的格式和内容。“始终验证”依靠安全编码而不是安全测试的概念和过程将大大提高应用程序的安全性。开始加强代码，以防止SQL首先注入封装。
何时及如何预防SQL注入
防止SQL理想的注入时间和地点是开发人员在其中IDE编写代码时。采用安全编码标准(例如C和C 的SEI CERT C和Java和.NET的OWASP Top 10或CWE Top 25)团队有未经验证的警告SQL查询输入标准。静态分析在新创建的代码上快速简单，易于集成CI/CD在这个过程中。现阶段调查所有安全警告和不安全编码是防止这个代码的好习惯写入内部版本。
检测不良代码实践的同样重要的部分是报告的实用性。能够理解静态分析违规行为的根本原因是很重要的，以便快速有效地解决它们。Parasoft的C/C test，dotTEST和Jtest等商业工具的发源地。
Parasoft在IDE解释并连续收集构建信息和其他信息。这些收集的数据、测试结果和指标可以全面了解团队编码标准的合规性。它还显示了整体质量和安全状态。
这些报告包括风险模型，包括风险模型OWASP，CERT和CWE提供的部分信息。这样，开发人员就可以更好地了解工具报告中潜在漏洞的影响，并优先考虑哪些漏洞。IDE所有级别生成的数据都与上述下游活动有关。
总结
臭名昭着的SQL注入漏洞继续困扰Web应用程序。虽然知道它是如何工作和可用的，但它仍然很常见。有关最新示例，请参见IoT Hall of Shame。我们提出了一种补充主动安全测试的预防和测试方法。这种方法可以防止在编写代码之前尽快SDLC中进行SQL注入。防止在IDE上进行SQL注入并在CI/CD在管道中检测到它们是将其路由到软件之外的关键。最后，在使用渗透测试技术的测试过程中发现和修复这些错误。
与SQL注入（使用其他污染数据）的斗争仍在继续。聪明的团队可以在他们现有的工作过程中扭转正确的过程、工具和自动化。