COL_LENGTH能否充分实现参数安全校验？

场景与现有实现 #

我维护的一个存储过程包含带ORDER BY子句的动态SQL，已在Try Catch块中对参数做了如下校验：

IF COL_LENGTH('dbo.TableName', @OrderByColumn) IS NULL
BEGIN
    RAISERROR('OrderByColumn not a recognized column', 16, 1);
END

IF (UPPER(@OrderByType) != 'ASC' AND UPPER(@OrderByType) != 'DESC')
BEGIN
    RAISERROR('OrderByType not a recognized direction', 16, 1);
END

随后通过CONCAT拼接动态SQL：

SET @OrderBySql = CONCAT(' Order By ', @OrderByColumn, ' ', @OrderByType) ;

但AI漏洞扫描工具认为存在SQL注入风险，提示内容如下：

SQL注入：该存储过程通过将@OrderByColumn、@OrderByType等用户提供的参数直接拼接进查询字符串来构建动态SQL。尽管使用了COL_LENGTH进行校验，但这种方法存在固有风险。攻击者可能绕过校验或利用边缘情况注入恶意SQL代码。更安全的方法是使用允许的列名和排序方向白名单，或采用带正确转义的参数化查询。

现有校验的有效性分析 #

现有校验在绝大多数场景下是安全的：

• COL_LENGTH('dbo.TableName', @OrderByColumn)会严格验证传入的列名是否存在于目标表中，任何包含注入语法的字符串（如ColumnName; DROP TABLE...）都会因不是有效列名而被拦截，返回NULL触发错误。
• 对@OrderByType的校验限制了只能是ASC或DESC（不区分大小写），排除了注入其他SQL语句的可能。

AI工具的提示更多是基于“动态拼接参数”的通用风险规则，实际在当前校验逻辑下，注入攻击的可行性极低。

更稳妥的优化方案 #

如果要彻底消除工具告警并进一步提升安全性，可以采用以下两种方案：

方案1：使用列名白名单 #

预先定义允许排序的列名单，仅接受在白名单内的列名，这种方式比验证列是否存在更严格，还能避免暴露表的全部列信息：

DECLARE @AllowedColumns TABLE (ColumnName NVARCHAR(128))
INSERT INTO @AllowedColumns VALUES ('Column1'), ('Column2'), ('Column3')

IF NOT EXISTS (SELECT 1 FROM @AllowedColumns WHERE ColumnName = @OrderByColumn)
BEGIN
    RAISERROR('OrderByColumn is not allowed', 16, 1);
END

方案2：用QUOTENAME包裹列名 #

即使列名包含特殊字符（如空格、关键字），QUOTENAME会自动添加方括号，避免语法错误或潜在的注入风险，配合原有的列存在性校验能进一步加固安全性：

SET @OrderBySql = CONCAT(' Order By ', QUOTENAME(@OrderByColumn), ' ', @OrderByType) ;

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