使用EXECUTE/USING构建XML的PL/pgSQL函数是否存在SQL注入风险？

咱们来把你的这些疑问逐个拆解清楚，毕竟动态SQL和SQL注入的坑有时候确实容易让人混淆：

1. 先明确：这个场景下不用USING真的有风险吗？ #

答案是有风险，哪怕你的函数不读写任何表。

SQL注入的核心是攻击者通过输入篡改SQL语句的结构，让数据库执行意料之外的逻辑。如果不用USING，直接把参数t拼接到EXECUTE的SQL字符串里，比如写成：

EXECUTE 'SELECT ''<'' || ''' || t || ''' || ''>''' INTO ret_val;

要是攻击者传入的t是'>; DROP TABLE some_table; --，拼接后的SQL就会变成：

SELECT '<' || ''>; DROP TABLE some_table; --' || '>'

这里的单引号直接闭合了原本的字符串，分号结束了SELECT语句，后面的DROP TABLE就会被当作合法SQL执行——哪怕你的函数原本只是想返回一个XML片段，也会触发恶意操作。

2. USING在这里到底起了什么作用？ #

你想直接写SELECT '<$1>'不行，因为字符串字面量里的$1会被当作普通文本，而不是参数占位符。而EXECUTE ... USING的机制是把参数绑定到SQL语句上，而不是把参数内容拼进SQL模板：

EXECUTE 'SELECT ''<'' || $1 || ''>''' INTO ret_val USING t;

这里的$1是参数占位符，PostgreSQL会把t的值作为独立的字符串参数传递，不管t里有什么特殊字符（单引号、分号、SQL关键字），都只会被当作字符串的一部分处理，完全不会篡改SQL语句的结构——从根源上杜绝了SQL注入的可能。

3. 拼接操作会不会抵消USING的防护？ #

完全不会！这里的拼接是在SQL执行阶段进行的：数据库会先把参数t的值和<、>这两个固定字符串拼接成一个完整的XML片段字符串，而不是把t的内容拼进EXECUTE的SQL模板里。

举个例子，哪怕t是'>; DROP TABLE some_table; --'，用USING的话，最终执行的逻辑只是生成字符串<'>; DROP TABLE some_table; -->，这就是一个普通的XML内容，不会执行里面的DROP语句。

4. USING对不涉及表操作的语句有效吗？ #

当然有效！USING的核心是参数绑定，和是否操作表没有任何关系。只要你用EXECUTE动态构造SQL语句，不管这个语句是返回常量、做计算还是查询表，用USING绑定参数都是防范SQL注入的标准做法。

最后，给你一个更优雅的替代方案 #

既然你不喜欢字符串拼接的方式，完全可以用PostgreSQL内置的XML函数来实现，根本不需要动态SQL：

CREATE OR REPLACE FUNCTION public.f1(t TEXT) RETURNS XML AS $BODY$
BEGIN
  RETURN xmlelement(name := t);
END $BODY$ LANGUAGE plpgsql IMMUTABLE;

甚至可以简化成更简洁的SQL函数：

CREATE OR REPLACE FUNCTION public.f1(t TEXT) RETURNS XML AS $BODY$
SELECT xmlelement(name := t);
$BODY$ LANGUAGE sql IMMUTABLE;

这种方式既避免了动态SQL的麻烦，又天然安全，完全不用担心SQL注入的问题。

内容的提问来源于stack exchange，提问作者404