邮件日志写入语句（INSERT INTO mail_log）是最常被忽略的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 结构与数据。
- 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}%'—— 模糊匹配既慢又增加注入面，真要查邮箱请用精确匹配或加全文索引专用表
最容易被忽略的一点：日志表权限和错误抑制
很多团队修完了主业务 SQL，却忘了给 mail_log 表单独配权限。如果这个表所属数据库用户仍有 DROP、CREATE 或 FILE 权限，预处理也挡不住攻击者通过日志注入提权。
- 执行：
REVOKE DROP, CREATE, FILE ON *.* FROM 'webapp'@'localhost'; - 日志写入失败时，不要输出 MySQL 错误（如
SQLSTATE[HY000]: General error），改用通用提示并记录到独立审计日志 - 检查是否启用了
log_warnings = 2（MySQL 5.7+），确保慢查询和语法错误被记录，方便回溯可疑插入
真正难的不是写对一条 prepare，而是确保所有日志入口——包括异步队列消费、重试任务、失败补偿逻辑——全部走同一套绑定流程。漏掉任意一个，漏洞就还在。
