如何在SQL中编写触发器以拒绝包含SQL注入特征的写入？-SQL-PHP中文网

sql触发器无法可靠拦截sql注入——注入发生在应用层字符串拼接阶段，触发器仅处理已解析的合法值，既无法识别原始恶意sql，也无法阻止语句构造；真正有效的是应用层参数化查询。

如何在sql中编写触发器以拒绝包含sql注入特征的写入？

SQL触发器无法可靠拦截SQL注入

直接说结论：你不能靠数据库触发器来防御SQL注入。这不是触发器的设计目标，也做不到真正安全。SQL注入是应用层把用户输入拼接到SQL语句中导致的，等数据进到触发器时，恶意内容已经是“合法字符串”了——触发器看到的只是普通文本，不是待执行的SQL代码。

触发器里能做的只是粗筛可疑字符串

如果你坚持在数据库侧加一层检查（比如遗留系统无法改应用代码），触发器最多对 INSERT 或 UPDATE 的字段值做简单模式匹配，比如检测单引号、分号、UNION、SELECT 等常见关键词。但这类规则极易误杀（比如用户真要存 “It’s a test; please check.”）或绕过（大小写变形、编码混淆、注释符绕过等）。

示例（PostgreSQL）：

CREATE OR REPLACE FUNCTION check_sql_injection()
RETURNS TRIGGER AS $$
BEGIN
  IF NEW.content ~* '(\b(SELECT|UNION|INSERT|DROP|EXEC|DECLARE)\b)|(;|--|\-\-|/\*|\*/|''|")' THEN
    RAISE EXCEPTION 'Possible SQL injection detected in content';
  END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

正则中的 \b 是单词边界，避免匹配到 “selection” 这类正常词
~* 表示大小写不敏感匹配，但攻击者可用 SeLeCt 或 %53%45%4c%45%43%54 绕过
完全无法识别 Base64 编码、Unicode 同形字、或利用 JSON 字段嵌套执行的场景

真正有效的做法只有一条路径

所有参数化查询必须由应用层完成，数据库只接收绑定参数后的纯值。这是唯一被验证有效的方案。

MiniMax 媒体生成

一款AI音频处理工具，主要用于MiniMax统一媒体生成技能，用于TokenPlan工作流。当用户要求生成音频、语音、TTS、旁白、图片、插图、姿势等媒体内容时使用，适合需要提升相关任务效率的用户。

下载

Python用 cursor.execute("SELECT * FROM users WHERE name = %s", [user_input])，而不是 "... WHERE name = '" + user_input + "'"
Java用 PreparedStatement，绝不用 Statement 拼接
Node.js用 pg.query('SELECT * FROM x WHERE y = $1', [input])，不用模板字符串直插
即使用了ORM（如Django ORM、Sequelize），也要确认它没开启原始SQL拼接开关（如Django的 extra()、raw()）

如果非要在数据库加校验，优先考虑CHECK约束而非触发器

CHECK约束更轻量、更声明式，且在语句解析阶段就生效。虽然能力仍有限，但比触发器少一层运行时开销，也更容易被查询优化器感知。

例如 PostgreSQL 中：

ALTER TABLE comments ADD CONSTRAINT no_semicolon CHECK (content !~ ';');

但注意：CHECK 无法调用函数（如正则匹配需用 ~ 运算符），也不能跨字段逻辑判断，更不能抛出带上下文的错误信息——它的作用就是快速拒掉最露骨的输入。

真正难防的是那些看起来完全正常的输入，比如一个看似无害的邮箱地址，却在应用层被错误地拼进动态SQL里。这种问题，数据库连“看见”的机会都没有。