存储过程安全性中的动态SQL

Question

我已经从地狱创建了SQL存储过程，并且为安全起见，所有输入参数都经过了参数设置，但是它的运行速度不如我想要的快，因此我想使其动态化，从而提高效率。

我知道我可以将输入参数保留到存储过程中，然后在其中创建一个动态SQL语句，然后可以在其中传递存储过程的输入参数，但是在执行此操作时我需要注意任何安全隐患？ 我猜不是因为它只是另一组参数，而且它们应该与传递给当前存储过程的参数一样对待。

显然，生成这样的代码“ WHERE OrderNo ='+ @orderno会带来麻烦-我将在动态SQL中执行'WHERE OrderNo = @orderno”，但是还有什么我需要注意的吗？

PS-在没有人建议的情况下，我无法使用LINQ或类似方法在客户端动态创建SQL-所有这些（由于各种原因）必须在数据库级别包含和控制

Answer 1

在存储过程中执行动态SQL时，有一种人们不会想到的SQL注入形式： SQL Truncation攻击 。

通过SQL截断攻击，攻击者注入了很长一段文本，使使用的文本变量溢出并丢失了部分查询。

本文提供了有关此的更多信息。

Answer 2

在您的参数始终为数据项的情况下，无论是传递给StoredProc 还是在DynamicSQL中使用它们，一切都将保持安全。

如果您的StoredProc的任何参数最终都是表名或字段名，从而成为DynamicSQL本身结构的一部分，则会带来新的风险：该参数可用于注入恶意SQL代码。

如何做到这一点的一个示例是使用输入参数作为令牌，而不是直接将其替换为DynamicSQL ...

SET @SQL = @SLQ + CASE targetTable WHEN '1'  THEN 'table1'
                                   WHEN 'tx' THEN 'tableX'
                  END

有人建议您只需要在客户端应用程序上进行验证。 但这意味着，如果有人能够直接执行您的SP，则SP就会成为攻击点。 我总是喜欢在客户端和服务器上都进行验证。

编辑效果

请注意，使用DynamicSQL并不总是保证性能的提高。 如果使用参数化查询，则可以存储执行计划。 但是，如果查询的确发生很大变化，则在编译SQL时仍可能会发现大量开销。

还有一个事实是依赖跟踪丢失了。 由于代码被隐藏为字符串，因此无法查看SP所依赖的表。

我很少发现需要DynamicSQL。 通常，复杂的查询可以重新构造为几个优化的查询。 或者可以重新构建数据以满足新的需求。 甚至重新考虑数据和使用数据的算法。 甚至可以暗示对DynamicSQL的依赖性是另一个潜在问题的指示。

也许这不在您的问题范围内，但是看到您实际面临的难题会很有趣。 看看是否有人对您有其他替代方法。