【问题标题】:SonarQube reports SQL injection on stored procedure nameSonarQube 报告存储过程名称上的 SQL 注入
【发布时间】:2026-02-13 17:50:01
【问题描述】:

我已经开始使用 SonarQube 进行静态分析。它向我报告了很多 SQL 注入漏洞,但它看起来是 false positive 发现的。

假设需要在数据库上运行过程。过程名称取自配置。

SonarQube 正在报告:

Make sure to sanitize the parameters of this SQL command.

示例代码:

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())
    {
    }
}

可以只在过程名称上进行任何 sql 注入吗?名称需要消毒吗?

【问题讨论】:

  • 如果您使用的是命令对象,则过程名称中没有 sql 注入漏洞。这段代码对我来说看起来非常干净和安全。
  • SonarQube 不知道如何填充“procName”。所以它显示了这条消息,但是您可以检查并查看是否没有入口点来使用动态输入对其进行修改,那么可以肯定地说它是误报。

标签: sql-server sonarqube sql-injection .net-4.6


【解决方案1】:

我承认 S3649 的实现并不是最聪明的,如果您将 非常量 字符串传递给 SqlCommandCommandText 属性或相应的 ctor 参数,则会引发问题.

如果您确定 CommandText 的值不是来自潜在的可利用来源,例如例如,查询字符串参数,处理此特定问题的最佳方法是在 SonarQube 中将其标记为Won't Fix。如果您还在此项目的连接模式下使用 SonarLint,它将自动禁止问题出现在 IDE 中。

另一方面,如果值可能来自可利用的来源,例如查询字符串参数、请求正文、cookie、标头等,设置CommandType = StoredProcedure 仍然不足以阻止攻击者执行不同的数据库上的存储过程比您预期的要好...在这种情况下,如果您为您拥有的存储过程创建单独的包装方法可能会更好,从而防止潜在的攻击者选择不同的 SP 来执行。

【讨论】: