Oracle中SQL注入高危点是EXECUTE IMMEDIATE和OPEN...FOR拼接用户输入，唯一安全修复是正确使用绑定变量；绑定变量必须脱离SQL字符串上下文，且仅适用于值而非表名、列名等结构化部分。
Oracle 中 SQL 注入问题，只要用了 EXECUTE IMMEDIATE 或 OPEN ... FOR 拼接用户输入，就大概率存在风险；而最直接、最有效的修复方式，就是改用绑定变量（Bind Variables）——不是“推荐做法”，而是 Oracle 官方明确要求的唯一安全路径。
为什么 Oracle 的字符串拼接特别危险
Oracle 对动态 SQL 的解析非常严格，但恰恰因为它的 PL/SQL 引擎允许在运行时构造完整语句（比如 EXECUTE IMMEDIATE 'SELECT * FROM users WHERE name = ''' || user_input || ''''），一旦 user_input 是 ' OR 1=1 --，整个语句就变成 SELECT * FROM users WHERE name = '' OR 1=1 --'，条件恒真，绕过校验。
这种拼接方式在 Oracle 中无法被数据库层自动识别为“参数”——它只看到一条已拼好的 SQL 字符串，连预编译都跳过了，自然不触发绑定变量的安全机制。
- PL/SQL 中
EXECUTE IMMEDIATE和OPEN ... FOR是高危入口点，必须检查所有传入的字符串是否含用户可控内容 - 即使加了
REPLACE或TRANSLATE过滤单引号，也挡不住 Unicode 编码绕过、宽字节截断、注释符组合等变体攻击 - Oracle 12c+ 的
DBMS_ASSERT包（如DBMS_ASSERT.SQL_OBJECT_NAME）仅适用于对象名校验，不能用于 WHERE 条件值
绑定变量怎么写才真正生效
关键不是“用了冒号”，而是变量是否脱离 SQL 字符串上下文。下面这几种写法，只有最后一种是安全的：
-- ❌ 错误：还是字符串拼接 EXECUTE IMMEDIATE 'SELECT * FROM emp WHERE deptno = ' || dept_id; <p>-- ❌ 错误：看似用了冒号，但实际是拼进字符串里的字面量 EXECUTE IMMEDIATE 'SELECT * FROM emp WHERE deptno = :1' USING dept_id;</p><p>-- ✅ 正确：绑定变量独立于 SQL 字符串，由 Oracle 引擎统一处理类型与转义 EXECUTE IMMEDIATE 'SELECT * FROM emp WHERE deptno = :1' USING dept_id;
注意：USING 子句中的变量必须是 PL/SQL 变量（如 NUMBER、VARCHAR2），不能是表达式或函数调用结果（如 USING UPPER(name) 不合法，需先赋值给变量再绑定）。
- 多个参数按位置顺序匹配，用
:1,:2… 或命名绑定:dept_id（需配合USING dept_id） - IN/OUT 参数需显式声明方向，例如
USING IN dept_id, OUT emp_name - 绑定变量不支持表名、列名、ORDER BY 子句等结构化部分——这些必须用
DBMS_ASSERT或白名单校验
Java / JDBC 连 Oracle 时的常见疏漏
很多人以为“用了 PreparedStatement 就万事大吉”，但在 Oracle 场景下仍可能翻车：
- 用
String.format()或+拼接 SQL，再塞进PreparedStatement—— 绑定变量根本没机会介入 - 对 Oracle 特有语法（如
FOR UPDATE SKIP LOCKED）做条件拼接，却把 where 部分写成字符串插值 - 调用存储过程时，把用户输入作为
IN参数传入，但过程体内又用EXECUTE IMMEDIATE二次拼接 —— 外层安全，内层裸奔 - MyBatis 中误用
${}（字符串替换）而非#{}（预编译绑定），尤其在<where></where>动态标签里混用
验证方法很简单：开启 Oracle 的 sql_trace 或查看 V$SQL 视图，如果同一条语句的 SQL_TEXT 出现多次且仅常量值不同（如 WHERE id = 123、WHERE id = 456），说明没走绑定；若只有一条带 :1 的记录，且 EXECUTIONS > 1，才是正确姿势。
哪些场景不能靠绑定变量解决
绑定变量只管“值”，不管“结构”。以下两类必须额外设防：
- 动态表名/视图名：必须走
DBMS_ASSERT.SQL_OBJECT_NAME(input)校验，否则EXECUTE IMMEDIATE 'SELECT * FROM ' || table_name依然可注入 - ORDER BY 列名或 ASC/DESC 方向：不能绑定，需白名单比对（如
CASE input WHEN 'name' THEN 'name' WHEN 'age' THEN 'age' ELSE NULL END） - UNION 查询的列数或类型对齐：若用户控制
UNION SELECT ...部分，绑定变量无能为力，必须禁止该类操作或用固定模板
真正难的从来不是写对一个 USING，而是把所有动态拼接点从代码里揪出来——尤其是嵌套在循环、异常处理块、或跨模块调用中的隐式拼接。Oracle 不报错，不代表安全；它只是默默执行了你“以为没问题”的那条语句。
