如果我在in子句中使用SQL参数，是否可以保护它免受SQL注入?

Question

下面是安全的SQL注入吗?用户将以字符串的形式传入一个逗号分隔的代码列表(例如:'1','1,3','1,2,3'等)。我读到SQL参数防止SQL注入。

CREATE PROCEDURE CurrentActions   
@StatusCodes nvarchar(100)   -- 0 = Active, 1 = Completed, 2 = On Hold
AS   
SELECT ActionId, ActionName, ActionStatusCode, Comments  
FROM Action
WHERE ActionStatusCode IN (@StatusCodes)
GO

似乎有人可以注入恶意代码到@StatusCodes，但我所读到的，情况并非如此，因为使用参数将防止这种情况。当使用动态SQL语句和不安全的连接时，参数可能会失败，但这里并没有发生这种情况。

所以我的猜测是它是安全的，然而，我无法找到任何具体相关的IN子句和插入到中间的字符串参数。是的，我知道还有其他方法来传递整型数组，但这是一种非常方便的方法。当然，它必须是安全的，否则我不会这样做。

谢谢。

Answer 1

你正在寻求做什么将不允许任何sql注入，但它也将不工作你想要的方式。

假设您通过@StatusCodes传递1,2,3这样的值。

This将NOT得到您希望的ActionStatusCode IN (1,2,3)表达式。相反，只有一个varchar值，所以你最终得到的更像是ActionStatusCode IN ('1,2,3')。类型不匹配意味着这可能甚至不会执行，如果它执行了，它只会将1,2,3视为一个连续的字符串，而不是三个独立的整数。

---

要解决这个问题，您的选项是表-值参数(我个人觉得很尴尬)，使用String_Split()在过程中分离值，或者将值一次一个发送到临时/会话/购物车表或类似的存储，当用户选择它们与JOIN一起使用时。

,没有这些选择中有一个特别棒。如果归结为它，我可能会使用String_Split，尽管我需要更舒适地使用ADO.Net的TVP。