C#与MySQL防注入实战：从字符串拼接到参数化查询的底层逻辑与避坑指南

大家好，我是零点博客的博主。在最近帮一位粉丝升级C#项目后端接口时，我发现了一个非常典型的“老生常谈”却又极易忽略的安全漏洞——SQL注入。这次复盘，我想抛开那些晦涩的理论，直接用实战代码和底层逻辑，聊聊如何在C#开发中彻底杜绝这种安全隐患。

一、踩坑现场：错误的拼接方式

在早期或者不严谨的代码中，很多小伙伴喜欢像拼积木一样拼SQL。比如在处理用户登录或数据查询时：

string sql = "SELECT * FROM Users WHERE Username = '" + txtUser.Text + "' AND Password = '" + txtPwd.Text + "'";
using (SqlCommand cmd = new SqlCommand(sql, conn))
{
    cmd.ExecuteNonQuery(); // 危险！

如果在输入框中输入 `admin' --` 或者 `1' OR '1'='1`，原本简单的查询就会变成恶意操作。这就是经典的SQL注入攻击。

二、正解：参数化查询（预处理语句）

C# 中的 SqlCommand 支持参数化查询。关键点在于，我们不再把用户输入的值直接拼接到SQL语句中，而是将其作为参数传递给数据库引擎。

string sql = "SELECT * FROM Users WHERE Username = @Username AND Password = @Password";
using (SqlConnection conn = new SqlConnection(connStr))
using (SqlCommand cmd = new SqlCommand(sql, conn))
{
    // 核心：使用 @ 符号定义参数，而不是字符串拼接
    cmd.Parameters.AddWithValue("@Username", txtUser.Text);
    cmd.Parameters.AddWithValue("@Password", txtPwd.Text);

    conn.Open();
    using (SqlDataReader reader = cmd.ExecuteReader())
    {
        // 业务逻辑处理
    }
}

你看，无论用户输入什么，数据库都把它当成一个字符串常量处理，而不会解析其中的SQL指令。

三、底层拆解：为什么它能防注入？

很多同学只知道用，不知道为什么。这涉及到数据库的执行机制：

语句解析分离：参数化查询发送的是两部分数据——SQL指令和参数值。数据库先解析指令结构，再填充参数。
类型强制：系统会强制将参数转换为指定类型（比如整型），这从源头杜绝了“注入”的语法结构。

四、联系开发：接口与JSON的安全性

在开发前后端分离的API接口时，这同样重要。我们常用JSON格式传输数据，比如：

{ "userId": "1001", "action": "delete" }

在后端C#处理时，切记不要相信前端传来的任何非空字符串。对于关键操作，必须进行二次校验，并结合正则表达式验证用户输入的格式，这样能构筑更坚固的防线。

五、总结与避坑指南

最后，给零点博客的各位小伙伴总结几个避坑点：

禁用拼接：永远不要在业务代码中拼接SQL字符串。
使用ORM：如Entity Framework Core，它底层自动帮我们处理了预处理语句，虽然稍微慢一点，但安全性和开发效率极高。
最小权限：数据库账号只给必要的权限，限制某些高危操作。

技术无绝对安全，只有不断的更新迭代。希望这篇关于C#安全开发的干货能帮到你！