C#/PHP防SQL注入实战：零点博客揭秘EMLOG源码与后端安全底层逻辑

大家好，我是零点博客的技术博主。最近在复盘EMLOG源码优化和C#接口开发时，发现一个很痛的点：很多开发者对SQL注入的防御存在侥幸心理。今天咱们不整虚的，直接通过PHP和C#两种后端语言的实战对比，结合MySQL数据库，把SQL注入这块硬骨头啃下来。

一、 排查现场：为什么代码里会有漏洞？

做爬虫开发时，如果你不去模拟一个恶意的User-Agent或者构造特殊的查询参数，你可能根本发现不了漏洞。最常见的写法就是字符串拼接。

1. PHP/EMLOG 惯犯写法

// 这种写法非常危险，直接把用户输入拼接到SQL里
$id = $_GET['id'];
$sql = "SELECT * FROM emlog_article WHERE gid = " . $id;

一旦传入 1 OR 1=1，数据库直接崩盘。EMLOG早期版本之所以频频被黑，很多都是这种“裸奔”写法。

2. C# 后端惯犯写法

string userId = Request.Query["id"];
string sql = "SELECT * FROM Users WHERE Id = " + userId;

C# 里用 StringBuilder 或者直接 + 号拼接，也是同理。如果不做处理，攻击者通过构造恶意参数，就能获取数据库所有数据。

二、 终极防御：预处理语句与参数绑定

解决方案很简单：把SQL语句和参数数据分开处理。这也就是所谓的预处理语句。

1. PHP 端改造 (PDO方式)

// 使用PDO连接MySQL，开启预处理
$stmt = $pdo->prepare("SELECT * FROM emlog_article WHERE gid = :id");
$stmt->bindParam(':id', $id, PDO::PARAM_INT);
$stmt->execute();

这样无论你传什么乱七八糟的字符，数据库只会把它当作文本，不会当作代码执行。

2. C# 端改造 (SqlCommand方式)

using (SqlCommand cmd = new SqlCommand("SELECT * FROM Users WHERE Id = @Id", conn))
{
cmd.Parameters.AddWithValue("@Id", Convert.ToInt32(userId));
}

C# 的 AddWithValue 会自动处理类型转换和参数化，从底层杜绝了注入风险。

三、 辅助检查：用正则表达式快速扫描

为了提升开发效率，我在零点博客的在线工具箱里写了一个简单的SQL注入正则表达式检测工具。

string pattern = @"/\b(SELECT|INSERT|UPDATE|DELETE|DROP)\b/i";

你可以把用户的输入放在这个正则里跑一下。如果有匹配，直接拦截，哪怕这只是个临时的接口开发方案，也比等着被黑强。

四、 总结与避坑指南

1. 永远不要相信用户的输入，无论是前端传来的 JSON 数据还是表单提交。

2. 无论你是做 PHP、C# 还是 Java，尽量使用 ORM 框架（如 Dapper, Entity Framework），它们默认就是参数化查询。

3. SQL 注入不仅仅是后端的事，如果你在做 HTML/CSS/JS 前端开发，也要注意防止 XSS 攻击，两者相辅相成。

技术无止境，防住 SQL 注入只是万里长征第一步。关注零点博客，下期分享如何用 C# 开发一个高并发在线工具，并解析 JSON 数据流。