问如何防止Mule应用程序中的SQL注入？

EN

根据最近的博客文章 (2017年10月12日)：

有一个全新的Mule 4数据库的任意点连接器(DB)，用户可以连接到不同的关系数据库引擎(MySQL数据库、Microsoft数据库、PostgreSQL数据库、Oracle等等)。

此新连接器仅在Mule 4中可用。

Mule 4

连接器引入的select操作允许使用参数化SQL查询，如下所示：

<set-variable variableName="table" value="PLANET"/>
<db:select config-ref="dbConfig">
 <db:sql>#["SELECT * FROM $(vars.table) WHERE name = :name"]</db:sql>
 <db:input-parameters>
   #[{'name' : payload}]
 </db:input-parameters>
</db:select>

使用这种方法，查询应该对SQL注入攻击产生免疫力。

这将迫使Mule运行时使用准备好的语句，该语句只编译一次。由于它是预编译的；参数将纯粹作为数据处理，因此不能用于更改SQL-查询的含义。因为查询不会被重新编译；传递的参数不能用于修改SQL查询。

有关详细信息，请参阅以下StackOverflow问题：

PreparedStatement如何避免或防止SQL注入？

这有助于避免某些类型的攻击，但这种解决方案不会使系统100%地对SQL注入免疫。

有关详细信息，请参阅有关安全StackExchange的以下问题：

准备好的语句对SQL注入是否100%安全？

根据这一点；通过使用带有参数化查询和白名单输入验证的准备语句，您可以避免某些/大多数类型的攻击，但不要认为您的系统是100%安全的。

在准备好带有参数化查询和用户输入清理的语句之后，您还需要设置其他防御线。

Mule 3.9

在Mule 3.9中，您可以使用参数化查询。

这是由运行时的"SimpleQueryTemplateParser“类实现的。

这将用问号替换查询文本中的MEL表达式，从而创建一个参数化SQL语句。

即使带有MEL表达式的SQL语句看起来有点可疑，它也不会简单地连接起来。

例如在以下情况下：

SELECT * from employee where name = #[flowVars.name]

#[flowVars.name]部件将被一个问号替换，它将被识别为一个SQL参数，并将创建以下查询：

SELECT * from employee where name = ?

MEL表达式将被识别和评估。它将作为参数添加。

也见正式文件。

如您所见，Mule 4的一个主要改进是它使用了命名的参数。

您可以使用yaml定义自定义策略，例如，它可以包括已批准字符的白名单，并在MuleSoft API管理器上强制执行安全策略。

在构建策略(如json和xml保护)中，也可以使用这些策略。

参考文献：

DZone:在MuleSoft中创建自定义策略

DZone: Cheatsheat -在MuleSoft API中解决OWASP的前10位可变性