<!DOCTYPE html>
开发在线工具必看:零点博客复盘 C# SQL注入防护与预处理实战
大家好,我是零点博客的主理人。最近在捣鼓一个基于 Web 的在线工具,涉及到了 C# 后端与 MySQL 的交互。刚开始写代码时比较随意,把用户输入直接拼接进了 SQL语句 里,虽然调试时没报错,但看着后台日志突然意识到这简直是引狼入室。
今天不整虚的,直接复盘一下我在开发过程中遇到的 SQL注入 风险点,以及我是如何通过参数化查询和预处理语句来“填坑”的。这对所有正在做 C# 或 PHP 接口开发的朋友来说,绝对是干货。
一、 坑点:拼接 SQL语句 的致命风险
很多刚入门的朋友,喜欢用字符串拼接,比如在处理 EMLOG 评论系统或用户登录接口时,可能会写出下面这种代码:
// ❌ 危险示例:直接拼接字符串
string userId = "1 OR 1=1";
string sql = $"SELECT * FROM users WHERE id = {userId}";
一旦用户传入的是这种特殊构造的字符串,整个数据表可能就被“脱裤”了。这就是典型的 SQL语句 注入攻击。
二、 破局:C# 中使用预处理语句与参数化
为了安全,我们必须将业务逻辑与数据逻辑分离。在 C# 操作 MySQL 时,微软推荐使用 MySqlCommand 配合参数化查询。这样做的好处是,无论你传入什么数据,程序都会把它当作“普通字符”来处理,而不会当成命令执行。
// ✅ 安全示例:使用参数化查询
using (MySqlConnection conn = new MySqlConnection(connString))
{
conn.Open();
// 使用 @符号 定义参数
string sql = "SELECT * FROM users WHERE id = @UserId";
using (MySqlCommand cmd = new MySqlCommand(sql, conn))
{
// 绑定参数,防止注入
cmd.Parameters.AddWithValue("@UserId", userId);
using (MySqlDataReader reader = cmd.ExecuteReader())
{
while (reader.Read())
{
// 读取 JSON 格式数据
string userData = reader.GetString("json_data");
Console.WriteLine(userData);
}
}
}
}
看,这就把风险扼杀在摇篮里了。不管是 C# 还是 PHP,核心思想都是一致的。
三、 前后端联调:JSON 与 正则解析
后端安全了,前端怎么配合呢?接口通常返回 JSON 格式的数据。在前端开发中,我们需要用 JavaScript 解析这些数据,或者用正则表达式校验格式。比如拿到用户名后,先用正则过滤一次,再发请求:
function validateAndSubmit(username) {
// 使用正则表达式简单校验用户名格式
const regex = /^[a-zA-Z0-9_]{4,16}$/;
if (!regex.test(username)) {
alert('用户名格式不正确');
return;
}
// 发起 AJAX 请求到后端 C# 接口
fetch('/api/checkUser', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ username: username })
})
.then(response => response.json())
.then(data => {
console.log('后端返回数据:', data);
});
}
四、 总结与源码分享
写代码其实就是在不断避坑。这次复盘让我深刻体会到,规范的 SQL语句 编写不仅仅是写法问题,更是代码安全的第一道防线。如果你也在做 EMLOG 二次开发,或者自己写在线工具,一定要养成用预处理语句的好习惯。
为了方便大家,我整理了一份包含上述 C# 后端逻辑、MySQL 建表语句以及 JSON 解析方法的完整源码案例,已经上传到了零点博客资源区。大家可以直接拿去改,不用自己从零写起。



评论一下吧
取消回复