如何修复由于邮件发送系统记录日志引起的SQL注入漏洞？-SQL-PHP中文网

邮件日志写入语句（insert into mail_log）是最常被忽略的sql注入入口，必须用预处理绑定参数修复，不可依赖过滤或转义；因其常被隔离在独立函数、不返回前端数据、权限较高且易被漏审，盲注风险突出。

如何修复由于邮件发送系统记录日志引起的sql注入漏洞？

直接结论：邮件日志写入语句（INSERT INTO mail_log）是最常被忽略的注入入口，修复必须用预处理绑定，不能靠过滤或转义。

为什么`mail_log`插入语句特别危险

很多人以为邮件发送本身走 SMTP，不碰数据库，就放松了对日志模块的审查。但实际中，INSERT INTO mail_log (to_email, subject, status) 这类语句往往直接拼接 $_POST['to'] 或 $_POST['subject']，且常被隔离在独立函数里，连 grep 都容易漏掉。更隐蔽的是，它不返回数据给前端，攻击者无法直接看到报错，但可通过盲注触发延时（如 SLEEP(5)）或写入异常状态来确认漏洞存在。

常见错误现象：mysql_query("INSERT INTO mail_log VALUES ('" . $_POST['to'] . "', '" . $_POST['subject'] . "', 'sent')") —— 一旦 to 字段传入 admin@example.com', 'xxx') -- ，整条语句逻辑就被破坏
邮箱字段尤其危险：MySQL 在宽松模式下可能把 'admin@example.com' OR 1=1# 当作合法字符串接收，拼进去后仍能执行条件分支
日志表通常权限较高（比如有 FILE 权限），攻击者可借此写 shell 或读取系统文件

必须用`prepare()` + `bind_param()`，别信`addslashes()`

addslashes()、mysql_real_escape_string() 或正则过滤 union/sleep 关键字，对现代 MySQL（尤其是开启 NO_BACKSLASH_ESCAPES 模式时）基本无效。唯一可靠路径是彻底分离 SQL 结构与数据。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

PHP + MySQLi 示例：

$stmt = $mysqli->prepare("INSERT INTO mail_log (to_email, subject, status) VALUES (?, ?, ?)");
$stmt->bind_param("ssi", $_POST['to'], $_POST['subject'], $status_code);
$stmt->execute();

PDO 示例：

$stmt = $pdo->prepare("INSERT INTO mail_log (to_email, subject, status) VALUES (?, ?, ?)");
$stmt->execute([$_POST['to'], $_POST['subject'], $status_code]);

绝对禁止：PDO::query("INSERT ... " . $_POST['to'])、mysqli_query($conn, "INSERT ... " . $_POST['subject'])
如果日志字段含 HTML 内容（如富文本正文），仍需在绑定前做 htmlspecialchars() 输出转义，但这和防 SQL 注入无关，别混淆

邮箱字段要双重校验：格式 + 绑定

仅靠预处理不够。攻击者可能传入超长字符串撑爆字段、或用 IDN 编码绕过前端限制。日志写入前必须做最小化净化。

先用 filter_var($_POST['to'], FILTER_VALIDATE_EMAIL) 校验格式，失败则拒绝写入
再统一转小写、去首尾空格：trim(strtolower($_POST['to']))，避免因大小写差异导致重复日志或索引失效
数据库字段定义必须匹配：例如 to_email VARCHAR(254)（RFC 5321 最大长度），不能设成 TEXT 或过宽的 VARCHAR(500)
禁止在日志查询中用 LIKE '%{$email}%' —— 模糊匹配既慢又增加注入面，真要查邮箱请用精确匹配或加全文索引专用表