在C#中如何重写SqlCommand执行逻辑以全面杜绝SQL注入？-SQL-PHP中文网

唯一可靠路径是严格使用 SqlParameter 替代字符串拼接，所有用户输入必须进参数，表名列名等动态结构须白名单校验，AddWithValue 须禁用并显式指定类型与长度。

在c#中如何重写sqlcommand执行逻辑以全面杜绝sql注入？

用 `SqlParameter` 替代字符串拼接是唯一可靠路径

直接拼接用户输入到 CommandText 中，无论加不加引号、转不转义，都挡不住 SQL 注入。C# 的 SqlCommand 本身不提供“重写执行逻辑”的钩子——它没开放底层解析或预处理流程。所谓“全面杜绝”，只能靠严格使用参数化查询，而非试图改造执行过程。

常见错误现象：string sql = $"SELECT * FROM Users WHERE Name = '{name}'";，哪怕 name 是 "admin' --"，也会让注释掉后续条件；更隐蔽的是 Unicode 同形字、宽字节截断（虽在现代 .NET 中极少见，但依赖编码层过滤仍是幻觉）。

所有用户可控输入（含 URL 参数、表单字段、HTTP Header、文件内容）必须进 SqlParameter
不要用 string.Format、$"..." 或 StringBuilder 拼接 SQL 主体结构
表名、列名、排序字段等无法参数化的部分，必须白名单校验（如 new[] { "Name", "Email", "CreatedAt" }.Contains(sortBy)）

`AddWithValue` 看似方便，实则埋雷

AddWithValue 会根据传入的 C# 值自动推断 SQL Server 类型，但推断常出错：比如传 null 推成 int，传 "123"（字符串）推成 varchar(3)，导致索引失效或隐式转换失败。它不解决注入，反而增加运行时不确定性。

正确做法是显式指定类型和长度：

cmd.Parameters.Add(new SqlParameter("@userId", SqlDbType.Int) { Value = userId });
cmd.Parameters.Add(new SqlParameter("@email", SqlDbType.NVarChar, 256) { Value = email ?? DBNull.Value });

对可空值，显式赋 DBNull.Value，别依赖 AddWithValue 的 null 处理
字符串参数务必指定长度（如 NVarChar(256)），避免 SQL Server 用默认长度（通常是 1）引发截断或计划缓存污染
数值类型优先用 SqlDbType.Int、SqlDbType.DateTime2 等精确类型，不用 SqlDbType.Variant

动态 SQL 场景下如何安全拼接 WHERE 条件

当搜索条件完全由前端控制（如多字段组合筛选），不能因为“要拼接”就放弃参数化。核心原则：SQL 结构（关键字、字段名、运算符）走白名单，值全部进参数。

错误示范：WHERE " + fieldName + " LIKE '%" + keyword + "%' —— 字段名和关键词全失控。

Browse website - Crawls sites automatically and mounts pages as markdown files you can grep, diff, cat, and explore with standard Unix commands — over SSH or HTTP

将任意网站转换为文件系统，自动抓取网站并将页面挂载为 Markdown 文件，可使用 grep、diff、cat 等标准 Unix 命令进行搜索、比较、读取和浏览。

下载

正确思路：

var conditions = new List<string>();
var parameters = new List<sqlparameter>();
<p>if (!string.IsNullOrWhiteSpace(name)) {
conditions.Add("Name LIKE @name");
parameters.Add(new SqlParameter("@name", SqlDbType.NVarChar, 100) { Value = "%" + name + "%" });
}
if (minAge > 0) {
conditions.Add("Age >= @minAge");
parameters.Add(new SqlParameter("@minAge", SqlDbType.Int) { Value = minAge });
}</p>
<p>cmd.CommandText = "SELECT * FROM Users WHERE " + string.Join(" AND ", conditions);
cmd.Parameters.AddRange(parameters.ToArray());</p></sqlparameter></string>

字段名、操作符（LIKE、=、BETWEEN）必须来自预设集合，不可来自请求原始值
每个动态条件对应一个独立参数，不复用参数名
避免在参数值中拼接通配符（如 "%" + value + "%"）——这属于业务逻辑，不是注入点，但需注意 NVarChar 长度是否覆盖完整值

存储过程调用也不能绕过参数化

有人误以为“调用存储过程就天然防注入”，其实不然。如果在 SP 内部用 EXEC(@sql) 或 sp_executesql 拼接动态 SQL，且参数未通过 @param 传入，照样中招。而从 C# 调用 SP 时，仍必须用 SqlParameter 传参，不能拼接 CommandText 为 "EXEC SearchUsers '" + name + "'"。

正确方式：

cmd.CommandType = CommandType.StoredProcedure;
cmd.CommandText = "SearchUsers";
cmd.Parameters.Add(new SqlParameter("@name", SqlDbType.NVarChar, 100) { Value = name });