在ASP.NET应用程序里，数据库操作如果直接拼接用户输入再发给SQL Server，就相当于把命令解释权让给了陌生人。使用SqlParameter对象可以把值和语句分开传递，由数据库驱动做类型绑定与转义，从机制上消除注入可能。下面先看一个最基础的用法示例。
为什么拼接SQL会被注入
很多老教程里会出现类似string sql = "select * from users where name='" + txtName.Text + "'";的写法。这种语句在用户正常输入时没有问题，但如果用户在文本框输入admin' or '1'='1，最终拼出的SQL变成了两条条件用or连接的查询，数据库会返回所有行。更危险的输入还能用;追加drop table等指令。
根本原因在于：拼接方式让“数据”和“指令”混在同一个字符串里，SQL引擎无法区分哪部分是程序员写的逻辑、哪部分是用户给的值。只要值里出现引号或注释符，语义就被篡改。解决思路不是过滤字符，而是彻底分离指令与数据，这正是SqlParameter的设计目的。
使用SqlParameter的基本写法
在ADO.NET中，我们可以构造带@参数名占位符的SQL，然后把SqlParameter加入Command的Parameters集合。下面的C#代码演示了根据用户名查密码哈希的安全写法：
using System.Data.SqlClient;
string connStr = "Server=.;Database=TestDb;Integrated Security=true;";
string sql = "SELECT password_hash FROM users WHERE username = @uname";
using (SqlConnection conn = new SqlConnection(connStr))
{
conn.Open();
using (SqlCommand cmd = new SqlCommand(sql, conn))
{
// 使用SqlParameter赋值，类型与长度由参数指定
cmd.Parameters.Add(new SqlParameter("@uname", System.Data.SqlDbType.NVarChar, 50));
cmd.Parameters["@uname"].Value = txtUsername.Text;
using (SqlDataReader reader = cmd.ExecuteReader())
{
if (reader.Read())
{
string hash = reader.GetString(0);
// 后续验证逻辑
}
}
}
}
上面代码里@uname只是占位符，无论txtUsername.Text里有什么内容，都会被当作纯字符串值传给数据库。SQL Server在预编译语句阶段就已经确定了执行计划，参数值不会影响语法结构。
除了手动new SqlParameter，也可以用更简洁的cmd.Parameters.AddWithValue("@uname", txtUsername.Text);。不过AddWithValue会根据值的类型推断SQL类型，有时会把短字符串推断成nvarchar，在索引匹配上略低效。对性能敏感的场景建议显式指定SqlDbType和长度。
调用存储过程时的参数赋值
当业务逻辑封装在存储过程中时，同样用SqlParameter传递。只需要把CommandType设为StoredProcedure，参数名与存储过程定义一致即可：
using (SqlCommand cmd = new SqlCommand("usp_check_login", conn))
{
cmd.CommandType = System.Data.CommandType.StoredProcedure;
cmd.Parameters.Add(new SqlParameter("@user", System.Data.SqlDbType.NVarChar, 50));
cmd.Parameters["@user"].Value = txtUsername.Text;
cmd.Parameters.Add(new SqlParameter("@pwd", System.Data.SqlDbType.NVarChar, 100));
cmd.Parameters["@pwd"].Value = txtPassword.Text;
int result = (int)cmd.ExecuteScalar();
// result为1表示登录成功
}
存储过程内部也应使用参数化语句，不要在过程体里再拼字符串。有些团队只在应用层用SqlParameter，但存储过程里用EXEC('select * from t where id=' + @id)，这依然有注入风险。参数化必须贯穿整条调用链。
另外，输出参数也通过SqlParameter设置Direction属性实现。例如获取用户剩余次数，可以加一个Direction为Output的参数，执行后从Value读取，全程不需要拼接，安全且类型明确。
常见误用与注意点
第一种误用是“假参数化”：SQL里写了@name，但值却用字符串格式化拼进去，比如string sql = string.Format("select * from t where name=@name", txt.Text);然后根本没有加Parameters。这样@name不会被替换，运行直接报错或依旧注入。必须保证每个占位符都在Parameters集合中有对应项。
第二种是表名或列名想用参数。SqlParameter只能替换值，不能替换标识符。如果需要根据用户选择动态换表，应先用白名单映射，例如用户选“订单”就对应变量tableName = "orders"，再用拼接（此时值来自代码常量而非输入）组成SQL，且绝不允许用户输入直接进标识符位置。
| 做法 | 是否安全 | 说明 |
|---|---|---|
| 字符串拼接用户输入 | 否 | 值和指令混合，易被篡改 |
| SqlParameter传值 | 是 | 数据与指令分离，推荐 |
| 存储过程内再拼SQL | 否 | 过程体未参数化仍有风险 |
| 白名单映射表名后拼接 | 是 | 标识符不来自用户输入 |
在Entity Framework中的对应关系
如果项目使用EF而非原生ADO.NET，LINQ查询本身就会翻译成参数化SQL。例如context.Users.Where(u => u.Name == input)，框架自动生成带@p0的查询。也就是说，只要不写context.Database.SqlQuery<User>("select * from users where name='" + input + "'")这种裸SQL，EF默认就是安全的。
当必须用FromSqlRaw时，要写成context.Users.FromSqlRaw("select * from users where name = @p0", input)，把输入作为后续参数传入，而不是格式化进字符串。这样底层依旧走SqlParameter机制，保持防护能力。
小结
防止SQL注入的核心原则是隔离指令与数据。在ASP.NET中，SqlParameter对象提供了简单可靠的赋值方式，无论是内联SQL还是存储过程都适用。开发中养成参数化习惯，避免任何用户输入直接进入SQL字符串，就能挡住绝大部分注入攻击，也让代码更清晰、便于排查问题。
ASP.NETSqlParameterSQL注入修改时间：2026-08-11 14:39:42