sp_executesql的替代方案

我读过调用sp_executesql会让SQL Server容易受到黑客攻击的问题。有没有一种现实的选择可以提供相同的灵活性？（我认为数据库应该只用于存储数据，但是我曾经工作过的任何地方都需要通过数据库进行业务逻辑。）sp_executesql的替代方案

来源

2017-05-08 Paul McCarthy

请发布您已阅读的内容的参考。 –

@GordonLinoff https://msdn.microsoft.com/en-us/library/ff648339.aspx – Intern87

@ Intern87。。。该问题不是'sp_executesql'。该问题正在执行由用户提供的代码。这只是'sp_executesql'的一小部分。如果使用正确，这并不危险。 –

遵循这些准则，您应该没问题; https://msdn.microsoft.com/en-us/library/ff648339.aspx

评论参数的应用程序的使用存储过程因为使用存储过程与参数不一定防止SQL注入，你应该检查你的应用程序使用的这种类型的存储过程。例如，以下参数化存储过程有几个安全漏洞。

CREATE PROCEDURE dbo.RunQuery @var ntext AS 
     exec sp_executesql @var GO

使用一个类似于在前面的代码示例的存储过程有下列漏洞的应用程序：存储的过程执行任何语句被传递给它。考虑将@var变量设置为： DROP TABLE ORDERS;在这种情况下，ORDERS表将被删除。存储过程以dbo权限运行。存储过程的名称（RunQuery）是一个糟糕的选择。如果攻击者能够探测数据库，他或她将看到存储过程的名称。使用名为RunQuery的名称，他可以猜测存储过程可能是以运行提供的查询。

安全的替换方案是用有效的参数

来源

2017-05-08 14:58:48 Intern87

sp_executesql运行存储过程是一样发放动态SQL几乎所有其他的方法是安全的。如果你参数化你的用户提供的输入（例如where子句和其他参数的值），那么它是相当安全的。如果你不这样做，它可能会对SQL注入攻击开放。没有什么我知道的，这使得sp_executesql比其他动态sql方法更安全。

请注意，将业务逻辑放入数据库也意味着使用存储过程。这些通常比允许发布任意SQL（即使参数设置正确）容易一些。当然，任何事情都可能实现得很差，并且仍然存在漏洞，但使用存储过程以及最大限度地减少真正动态SQL的使用还有其他好处。

结帐the MSDN article describing how to use parameters with sp_executesql

来源

2017-05-08 14:59:58 SlimsGhost

sp_executesql的替代方案

回答

相关问题