参数化查询中使用string_split()是否存在SQL注入风险？

你这个写法100%可以防SQL注入，没有安全隐患。

原理说明 #

SQL注入能生效的核心逻辑只有一个：用户输入的内容被拼接进了SQL语句文本，被数据库当成代码语法的一部分解析执行了。

• 你这里的@commaSeparatedListOfValues是通过参数化方式传入的，从传给数据库开始，它就始终是一个纯字符串值，数据库从来不会把它的内容当成SQL命令解析。
• string_split()本身是纯字符串处理函数，输入是字符串值，输出也是拆分后的字符串表值，整个处理过程不会重新解析、执行任何SQL逻辑。

你举的那个恶意输入样例：

"firstValue , ');PRINT 'Hello'-- , thirdValue"

经过string_split()拆分加TRIM()处理后，只会得到三个普通的字符串值：

• firstValue
• ');PRINT 'Hello'--
• thirdValue

这些值只会被拿来和SomeColumn做等值匹配，不会被当成SQL指令执行，最多就是匹配不到对应数据返回空结果而已，不会触发任何恶意操作。

唯一需要避开的坑 #

只有一种情况会出风险：如果你后续把拆分出来的值直接拼接到动态SQL语句里执行，比如写类似下面的代码：

DECLARE @sql NVARCHAR(MAX)
SET @sql = 'SELECT * FROM SomeTable WHERE SomeColumn IN (' + @splitValue + ')'
EXEC(@sql)

这种把值直接拼进SQL文本的写法才会给注入留可乘之机，但你现在写的静态查询里直接用子查询做IN匹配的写法，完全不存在这个问题。

另外你用TRIM()处理拆分后的值是很实用的细节，能避免用户输入逗号前后带空格导致匹配失效的问题。

内容的提问来源于stack exchange，提问作者roboblocky