零点博客实战复盘：从手写SQL到预处理语句，彻底告别SQL注入

做C#后端开发这么久，从早期的拼SQL字符串到后来接触EMLOG等CMS系统的底层代码，我对数据库交互的理解越来越深。今天想和大家掏心窝子聊聊一个老生常谈却始终绕不开的话题——SQL注入防护。

相信很多刚入行的同学跟我以前一样，为了图方便，习惯直接用字符串拼接去拼SQL。但在接口开发中，这种写法简直是定时炸弹。本文将结合零点博客的实际开发经验，用最接地气的语言拆解预处理语句的原理，并给出C#实战案例。

一、还在拼字符串？你的代码正在裸奔

以前写PHP或C#时，如果不习惯用ORM，很容易写出这样的代码：

// 危险示例：传统拼接SQL
string sql = "SELECT * FROM users WHERE username = '" + inputUser + "'";

在后台接收前端传来的用户名，如果用户输入的是 admin' --，这时候SQL语句就会变成恶意查询，直接绕过验证。

这种低级错误，在线工具开发时更是灾难。为了解决这个问题，预处理语句应运而生，它是现代Web开发的安全基石。

二、预处理语句到底是个什么鬼？

简单来说，预处理语句将SQL语句的结构和SQL语句的数据分开了处理。

当你把SQL发给数据库服务器时，服务器会先编译SQL语句的“骨架”。之后你再传参数进去，数据库只是把“肉”填进“骨架”里，而不会重新解析SQL语句。这意味着，即便参数里包含恶意符号，数据库也会把它当成普通字符串处理，根本构不成指令。

三、 C# 后端实战：从底层到底层

虽然Entity Framework (EF) 和 Dapper 等工具封装得很好，但了解底层原理能帮你更好地排查问题。下面是使用原生 ADO.NET 实现预处理语句的案例：

案例：获取用户信息接口

using (SqlConnection conn = new SqlConnection(connectionString))
{
    // 1. 先发送SQL骨架，不需要插入参数，只定义参数占位符(@UserId)
    string sql = "SELECT * FROM Users WHERE UserId = @UserId";

    using (SqlCommand cmd = new SqlCommand(sql, conn))
    {
        // 2. 添加参数，自动处理转义，防止注入
        cmd.Parameters.AddWithValue("@UserId", inputUserId);

        conn.Open();
        using (SqlDataReader reader = cmd.ExecuteReader())
        {
            if (reader.Read())
            {
                // 3. 解析JSON或直接返回结果
                Console.WriteLine("用户名: " + reader["UserName"]); 
            }
        }
    }
}

看，通过 Parameters.AddWithValue，我们不需要自己去拼加号或者转义单引号。这种写法，在处理大量用户数据或复杂的JSON数据解析时，稳定性远高于字符串拼接。

四、避坑指南与底层逻辑

在开发在线工具（比如SQL格式化工具或数据生成器）时，我总结了几点经验：

永远信任前端传来的数据：无论看起来多安全，接口开发中必须对每个变量进行校验，哪怕是在内存中先转义。
尽量用ORM：虽然底层原理是一样的，但EF Core 会自动生成预处理语句。如果你看到报错提示参数类型不匹配，那很可能是忘了在实体模型上做配置。
避免动态SQL过度：在存储过程或复杂查询中，如果必须动态拼表名或列名，请务必用存储过程或严格白名单控制，否则安全防护形同虚设。

掌握了预处理语句，你就拿住了Web开发安全的大门。如果你在C#爬虫开发或EMLOG插件开发中遇到数据库交互问题，欢迎在零点博客评论区留言，我们一起深挖。