PostgreSQL安全PL/pgSQL函数防注入编写指南

在PL/pgSQL里写动态SQL，很多开发者最先想到的防护就是 quote_ident()。但如果你觉得只要套上这个函数就万事大吉，那可真是踩进了一个大坑。

先说结论：动态拼接表名或字段名时，quote_ident() 只能算是最低限度的防御，绝对不够用。它只负责把你传进来的字符串用双引号包起来，再把里面的反斜杠转义一下。但问题是，它从来不问“你这字符串到底是不是一个合法的标识符”。来看一个典型例子：你传进来一个 'users; DROP TABLE accounts; --'，quote_ident() 会把它转换成 "users; DROP TABLE accounts; --"。你看，双引号是包上了，可这句话放到 EXECUTE 'SELECT * FROM ' || quote_ident(user_input) 里，它仍然是语法上合法的标识符——数据库不会报错，也不会拦截后面的恶意操作。等于说，你给了攻击者一本正经构造恶意字符串的通行证。

那真正安全的做法是什么？很简单：先白名单校验，再调 quote_ident()。举个例子，你可以只允许输入由字母、数字、下划线组成，长度不超过64个字符，并且不能以数字开头：

IF user_input !~ '^[a-zA-Z_][a-zA-Z0-9_]{0,63}$' THEN
  RAISE EXCEPTION 'invalid identifier: %', user_input;
END IF;

• 正则白名单必须放在 EXECUTE 之前执行，不能指望 quote_ident() 来兜底。
• 处理表名或字段名时，千万不要用 quote_literal()——它给你加的是单引号，一执行就语法报错。
• 也别直接把用户输入扔进 format() 的 %I 占位符里，除非你已经做了白名单过滤。

动态查询中传参必须用 USING，不能拼进 SQL 字符串

这条坑埋得特别深，也特别容易被忽略。你可能会觉得自己已经用 quote_ident() 安全地处理了表名，WHERE 条件里的值随便拼一下也没事——但就是这“随便拼一下”，可能直接把注入入口暴露给攻击者。

-- 危险！拼接值 = 注入入口
EXECUTE 'SELECT * FROM ' || quote_ident(tbl) || ' WHERE id = ' || user_id;

业内公认的正确写法，是把查询值作为参数传给 EXECUTE ... USING：

EXECUTE 'SELECT * FROM ' || quote_ident(tbl) || ' WHERE id = $1' USING user_id;

• USING 后面的变量，数据库引擎会当作纯粹的数据绑定，完全脱离 SQL 解析上下文——这等于从根上断了注入的路。
• 支持多个参数，比如 USING val1, val2, val3，对应 SQL 里的 $1, $2, $3。
• 有一点必须牢记：USING 里不能传表名、字段名、ORDER BY 子句——这些还是得走白名单 + quote_ident() 的组合拳。

COPY 命令在函数里绝对禁止拼接路径

这大概是最容易被忽视的高危操作了。在 PL/pgSQL 函数里写 EXECUTE 'COPY users FROM ''' || filename || ''''，等于直接给攻击者开了一扇任意文件读取的大门。比如攻击者可以调用 load_csv('/etc/passwd')，直接把系统密码文件泄露出去。

生产环境下，唯一靠谱的方案是：彻底放弃在服务端用 COPY，改为由应用层流式导入（比如 Python 的 cursor.copy_expert()）。如果实在绕不开，必须满足以下三个条件：

• 路径必须硬编码，比如 '/var/lib/postgresql/import/users.csv'，绝对不要允许任何变量参与路径拼接。
• 数据库角色必须撤销 pg_read_server_files 和 pg_write_server_files 权限。
• 函数本身用 SECURITY DEFINER 并限制为只读角色，只对特定目录有访问权限。

为什么不用 format() 的 %L 或 %I 就容易出事

format() 用起来确实方便，但它的占位符行为完全依赖你传入的参数类型和上下文。比如 %L 对空字符串、NULL、特殊字符的处理，远不如 quote_literal() 稳定；%I 虽然等价于 quote_ident()，但它同样不会主动拒绝非法输入——它只是尽力转义，而不是校验。

更麻烦的是，在嵌套调用或复杂表达式里，format() 很容易漏掉某个占位符，导致未格式化的原始输入直接混进最终 SQL。所以建议这样处理：

• 优先拆解逻辑：白名单校验 → quote_ident() / quote_literal() → EXECUTE ... USING，步步到位。
• 避免在同一个 format() 调用里同时处理标识符和值。
• 测试时一定要覆盖边界输入：空字符串、单引号、分号、反斜杠、Unicode 控制字符——一个都不能少。

说到底，写对一行 EXECUTE 并不难，难的是确保函数里的每一条分支路径——IF 分支、异常处理块、循环体里的每一次拼接——都经过相同的安全检查。这才是真正的安全底线。