网络安全检测|网络安全服务|网络安全扫描-香港墨客投资移动版

　　在某些情况下，攻击者可能根本无法从数据库获得任何反馈。在这种情况下，它们可以强制数据库将输出重定向到另一个位置，并尝试从那里读取它。这就是所谓的带外SQL注入。例如，他们可以强制数据库将包含敏感信息的DNS查询发送到他们控制的DNS服务器。或者，它们可以强制数据库将一些数据写入可公开访问的文件中。这种注入会影响许多数据库。

　　减轻SQLi时的常见错误

　　用户不应该试图为SQL输入参数提供自己的清理程序。这样做需要深入了解数据库规范和使用它们的经验。最有可能的是，最终会淹没在其他人无法理解的正则表达式中，并且随着数据库的发展，没有人会支持清理程序。

　　需要记住：攻击者总是试图混淆他们的SQLi有效负载，将其偷运到WAF和IPS。有大量的框架可以利用SQLi，为攻击者提供扭曲有效负载的脚本库。编写自定义混淆处理程序并将其与现有混淆处理程序结合使用也很容易。

　　考虑一下开发人员在试图净化用户输入时所犯的一些常见错误。

　　一个常见的误解是，可以通过删除/替换SQL查询参数中的空格来避免SQLi。例如，如果攻击者只能使用一个单词，会造成多大的伤害?但是许多数据库将注释转换为空格，因此“SELECT email FROM user”等于“SELECT/**/email/**/FROM/**/user”，这是一个单词。

　　使用注释而不是空格的SQLMap篡改脚本

　　通常认为删除引号可以使参数安全，但有时攻击者可以指定另一个特殊字符来定义字符串。例如，PostgreSQL允许定义包含在双美元符号中的多行字符串。所以“email”等于$$ email$$。

　　SQLMap篡改脚本，使用双美元符号代替单引号

　　最后但并非最不常见的错误是对数据库关键字进行非递归删除。这也很容易绕过检测，因为攻击者可以在相同的关键字中间插入关键字。因此，经过清理之后，注入仍然存在。例如：

　　“SELSELECTECT” -> “SELECT”

　　用于嵌套关键字的SQLMap篡改脚本

　　防止SQL注入的正确方法

　　防止SQLi的第一步是使用预处理语句。允许用户定义预处理语句也是不可接受的。这里有一个使用TypeORM防止SQL注入的例子：采用硬编码的模板，并使用这个框架的特性来安全地插入变量：

　　使用TypeORM编写语句

　　但是仅仅使用ORM是不够的。正如前面看到的，业务逻辑缺陷可以允许绕过安全保护措施。SQLi修正的第二步是显式验证用户输入。如果需要一个数字，可以手动将值转换为数字。如果需要URL，可以手动将输入字符串转换为URL。这种方法显著降低了利用SQLi的可能性。额外的好处是，将拥有更一致的数据和更少的错误。有许多库可用于声明性验证，例如express-validator或class-validator。

　　另一件需要记住的重要事情是始终为每个应用程序创建一个专用的数据库用户。仔细阅读有关默认用户权限的文档，并禁用除了对应用程序运行至关重要的功能之外的所有功能。除了数据库管理之外，永远不应该将DBA帐户用于其他任何事情。默认情况下，DBA帐户被授予所有可能的权限。这显著地放大了SQL注入的严重性。

　　最后但同样重要的是，使用Web应用程序防火墙或入侵预防系统。它们能够发现并破坏SQL注入攻击，甚至有一组流量规则来检测依赖SQLi的已知漏洞。当然，使用WAF或IPS并不是灵丹妙药，因为它们可以绕过检测。然而，这种工具的存在显著提高了进行攻击所需的知识阈值。另外，WAF/IPS干扰了SQLi开发自动化，并提供了比传统工具更好的日志记录。