这种构建动态 SQL 的方法是否容易受到 SQL 注入的影响或对性能不利？答案

【问题标题】：Is this method of building dynamic SQL vulnerable to SQL injection or bad for performance?这种构建动态 SQL 的方法是否容易受到 SQL 注入的影响或对性能不利？
【发布时间】：2011-10-05 21:02:13
【问题描述】：

我想构建一个可以处理多个 WHERE 子句的安全动态选择语句。

例如，基本 SQL 如下所示：

SELECT * FROM Books Where Type='Novel'

我会传递这样的函数：

SafeDynamicSQL("author,=,Herman Melville","pages,>,1000");

这会清理输入并像这样连接：

SELECT * FROM Books Where Type='Novel' AND author=@author AND pages>@pages

该函数将通过检查一组预定义的列名来清理列名。运算符只能是 >,

这仍然容易受到 SQL 注入的攻击吗？

会有一些字符串操作和小循环会影响性能，但我的想法是，与平均需要 200 毫秒的请求相比，这将只需要几毫秒。如果这些请求大约每秒发出一次，这会对服务器造成比我想象的更多的负担吗？

我知道这无论如何都不是最佳实践，但它会大大加快开发速度。请告诉我这可能是个坏主意的任何其他原因。

【问题讨论】：

标签： sql performance security dynamic-sql

【解决方案1】：

看起来您正在重新发明任意数量的现有 ORM 解决方案，这些解决方案提供类似的 API 来创建 WHERE 子句。

您的问题的答案取决于您所说的“该值将作为普通参数添加”。如果您的意思是执行字符串连接以生成您显示的字符串，那么是的，那仍然会受到 SQL 注入攻击。如果您的意思是使用实际的参数化查询，那么您将是安全的。在后一种情况下，你会产生类似的东西

 SELECT * FROM Books Where Type='Novel' AND author=? AND pages > ?

然后将其绑定到一个值列表，例如 ['Herman Melville', 1000]。具体的外观取决于您使用的编程语言。

最后，如果您选择这条路，我强烈建议您将逗号分隔的参数更改为三个单独的参数，这样可以节省大量编程时间。

【讨论】：

感谢拉里的建议。你是对的，我忘了把参数化的值放在我的例子中。我更喜欢 codegens 烤箱 ORM，这就是我在这里重新发明轮子的原因。
通过此修改，您应该可以避免 SQL 注入。

【解决方案2】：

从安全的角度来看，几乎任何将字符串附加在一起（或插入）以创建 SQL 的代码都是错误的形式，并且可能会受到某些 SQLi 攻击向量的影响。只需使用绑定参数并避免整个问题；避免 SQL 注入非常容易。

【讨论】：