如何防止Oracle动态SQL产生SQL注入漏洞？

EXECUTE IMMEDIATE 必须配 USING 绑定变量，严禁拼接字符串；表名列名等标识符须白名单校验；IN 子句需用预设占位符或集合类型处理，不可动态展开。

EXECUTE IMMEDIATE 必须配 USING，不能拼字符串

Oracle 动态 SQL 的最大风险来源就是 EXECUTE IMMEDIATE 拼接用户输入。只要 SQL 字符串里出现 || user_input 或 || '''' || name || '''' 这类操作，就等于把执行权交出去了。

正确做法是让 SQL 字符串完全静态，所有外部值只通过 USING 传入：

1. EXECUTE IMMEDIATE 'SELECT * FROM emp WHERE deptno = :d' USING dept_id; ✅ 安全
2. EXECUTE IMMEDIATE 'SELECT * FROM emp WHERE deptno = ' || dept_id; ❌ 危险
3. EXECUTE IMMEDIATE 'SELECT * FROM emp WHERE name = ''' || name || ''''; ❌ 即使加了单引号转义也挡不住 Unicode 绕过

USING 后的变量必须是 PL/SQL 变量（如 VARCHAR2、NUMBER），不能是表达式——USING UPPER(name) 不合法，得先 l_name := UPPER(name); 再 USING l_name。

IN 子句不能直接绑定变长数组

想用 WHERE id IN (:a, :b, :c) 并动态塞进 5 个值？Oracle 不支持运行时展开绑定列表，会报 ORA-01008: not all variables bound。

安全方案只有两个：

1. 用嵌套表 + MEMBER OF：WHERE id MEMBER OF :id_list，绑定 sys.odcinumberlist(1,2,3)
2. 预设固定长度（如最多 10 个）：WHERE id IN (:1,:2,...,:10) AND id IS NOT NULL，未用位置传 NULL

千万别用 LISTAGG 拼字符串再 INSTR 查——这等于绕开绑定，重回高危区。

表名、列名等结构信息不能绑，但也不能裸拼

OracleParameter 和 USING 只保护“值”，不保护对象名。直接拼 'SELECT * FROM ' || user_table 就是给攻击者留后门。

必须走白名单校验或 DBMS_ASSERT：

1. DBMS_ASSERT.SIMPLE_SQL_NAME(user_table) —— 非法字符直接抛异常
2. 查字典视图确认存在：SELECT 1 FROM all_tables WHERE table_name = UPPER(:tname) AND owner = USER
3. 禁用点号、双引号、美元符；正则 ^[a-zA-Z][a-zA-Z0-9_]{0,29}$ 是底线，但不能替代存在性校验

排序字段等动态结构，要用 CASE WHEN :sort_by = 'name' THEN name END 预置逻辑，而不是尝试绑定 :col。

.NET 中 OracleCommand.CommandText 必须是静态字符串

在 .NET 里，OracleParameter 生效的前提是：CommandText 本身不含任何用户输入拼接。

常见错误写法：

1. cmd.CommandText = $"SELECT * FROM users WHERE name = '{name}'"; —— OracleParameter 完全无效
2. cmd.CommandText = "SELECT * FROM users WHERE name = @p"; —— Oracle 不认 @p，要用 :p

正确写法：

1. cmd.CommandText = "SELECT * FROM users WHERE name = :p";
2. cmd.Parameters.Add(new OracleParameter("p", name)); —— 参数名 "p" 必须和 :p 完全一致（大小写敏感）

命名绑定比位置绑定（?）更可靠，尤其涉及 REF CURSOR 或 PL/SQL 块时，? 容易出错。

真正难的不是写对一个 USING，而是所有动态点都得同步处理：值走绑定、结构走白名单、IN 走集合、排序走 CASE——漏掉任意一环，整条链就断了。