SonarQube报存储过程名SQL注入：是否为误报？需sanitize吗？

1. 当前代码是否存在SQL注入风险？ #

答案是完全没有。

你代码里的关键操作是设置了cmd.CommandType = CommandType.StoredProcedure——当用这个配置时，SqlCommand会直接将procName作为存储过程的标识符传递给SQL Server，而非把它当作可执行的SQL文本内容。数据库会直接查找匹配名称的存储过程并执行，不会解析procName中的特殊字符（比如;、'这类注入常用符号）。

对比危险写法：如果是通过字符串拼接生成SQL文本（比如"EXEC " + procName），且使用CommandType.Text，那才会存在注入风险——因为数据库会把整个拼接后的字符串当作SQL语句去解析执行，恶意的procName可以插入额外的SQL命令。但你的写法完全规避了这个问题。

2. 存储过程名是否需要做sanitize处理？ #

分两种场景判断：

• 如果procName来自可信来源（比如应用配置文件、内部常量，而非用户输入或外部不可信数据）：不需要额外做sanitize处理，因为来源可控，不会有恶意内容。
• 如果procName来自不可信来源（比如用户输入、第三方接口传入）：此时虽然不会有SQL注入风险，但可能存在其他安全问题（比如调用数据库中存在的恶意存储过程、越权执行敏感存储过程）。这种情况下，白名单校验比普通sanitize更可靠——你应该预先定义允许调用的存储过程列表，只允许传入的procName在这个列表内，而非单纯过滤特殊字符（sanitize可能遗漏某些场景）。

3. 为什么SonarQube会报误报？ #

SonarQube的静态分析规则多基于模式匹配——它检测到你直接使用变量作为SQL相关参数（这里是存储过程名），但没有区分你是用在CommandType.StoredProcedure场景还是普通SQL文本场景，因此触发了通用的SQL注入警告。你可以在SonarQube中将这个标记为误报，或者调整规则配置，让它忽略CommandType.StoredProcedure下的存储过程名参数。

你的安全示例代码：

using (SqlCommand cmd = new SqlCommand(procName, Connection)) 
{ 
    cmd.CommandType = CommandType.StoredProcedure; 
    cmd.Parameters.Add(new SqlParameter("@param", SqlDbType.NVarChar, 32)).Value = record; 
    using (SqlDataReader dr = cmd.ExecuteReader()) { } 
}

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