Oracle中PreparedStatement无法参数化表名、列名等标识符，因其属SQL解析前必须确定的语法结构；唯一安全方案是用户输入仅作白名单键映射真实名称，严禁动态拼接或使用${}、EXECUTE IMMEDIATE等绕过机制。
Oracle中无法用?占位符绑定表名、列名、PL/SQL包名或EXECUTE IMMEDIATE中的任意结构化部分——这不是驱动或语法限制，而是SQL协议本身的硬性约束。所有试图“参数化”这些位置的尝试（比如setString(1, "my_table")）都只是字符串拼接，等同于直接拼SQL。
为什么PreparedStatement对表名/包名完全无效
Oracle JDBC的PreparedStatement只在SQL语句解析阶段将?替换为绑定值，并交由数据库执行计划引擎处理；但表名、列名、函数名属于**语法结构标识符**，必须在解析前就确定，不能延迟到执行时。所以以下写法必然失败：
String sql = "SELECT * FROM ? WHERE id = ?"; // 语法错误，Oracle直接报ORA-00903: invalid table name
更隐蔽的是这种“看似安全”的伪参数化：
String sql = "SELECT " + userInputPackage + ".do_something() FROM dual"; // 即使userInputPackage来自DB配置，也照样注入
- 攻击者可输入
DynamicallyNamedPackage.DoThisDynamicallyNamedThing OR 1=1 --，触发任意PL/SQL逻辑 -
setString()对这类输入不做任何拦截或转义，它只负责把值传给绑定变量机制，而这里根本没绑定变量 - Oracle不校验包名是否合法，只要语法能解析就执行——包括调用
UTL_HTTP.request或DBMS_SCHEDULER
动态表名/包名必须走白名单映射
当业务确实需要运行时决定查哪张表、调哪个包（如分表日志、多租户包隔离），唯一合规路径是：用户输入仅作为**键**，查预定义的白名单枚举或Map，再映射到真实对象名。
示例（JPA + 枚举）：
public enum OraclePackage {
USER_LOG_PKG("USER_LOG_PKG"),
ORDER_2026_PKG("ORDER_2026_PKG"),
AUDIT_PKG("AUDIT_PKG");
<pre class="brush:php;toolbar:false;">private final String realName;
OraclePackage(String realName) { this.realName = realName; }
public String getRealName() { return realName; }
}
// 使用时 String input = request.getParameter("pkg"); // 来自HTTP或DB属性 OraclePackage pkg = Arrays.stream(OraclePackage.values()) .filter(p -> p.name().equalsIgnoreCase(input)) .findFirst() .orElseThrow(() -> new IllegalArgumentException("Invalid package: " + input));
String sql = "SELECT " + pkg.getRealName() + ".get_count() FROM dual"; Query query = em.createNativeQuery(sql); // 此处sql已无用户可控内容
- 白名单必须硬编码或从可信配置中心加载，禁止从数据库表、文件、环境变量动态读取（否则白名单本身被污染）
- 枚举名和
realName要分离——用户只能看到枚举名（如USER_LOG_PKG），不能接触真实包名（如LOG_PKG_202610） - 拒绝所有未明确定义的输入，包括空字符串、null、带点号或斜杠的字符串
EXECUTE IMMEDIATE和MyBatis ${} 是高危区
这两处完全绕过PreparedStatement保护，等同于Java里的String.format。只要用户输入进入EXECUTE IMMEDIATE '...'||user_input或MyBatis的${tableName}，就等于开放SQL执行权限。
- 在PL/SQL中，
EXECUTE IMMEDIATE 'SELECT * FROM '||user_table和Java里"SELECT * FROM " + user_table安全等级完全相同 - MyBatis的
${}只应在模板常量中使用，例如${@TBL_PREFIX@}_users，且@TBL_PREFIX@必须是编译期确定的字符串字面量 - JPA的
@Query(value = "...", nativeQuery = true)若含+拼接或String.format，同样失效
权限收紧是最后一道防线
即使白名单校验漏掉一个包名，最小权限也能阻止横向移动。生产库账号必须禁用以下权限：
-
EXECUTE ANY PROCEDURE（允许调用任意包） -
SELECT ANY TABLE（可跨schema查敏感表） -
UTL_HTTP、UTL_TCP、DBMS_LOB等高危包的EXECUTE权限 - JDBC URL中显式关闭危险选项：
allowMultiQueries=false（防堆叠注入）、useFetchSizeWithLongColumn=true（防长字段解析异常）
真正难的不是写白名单逻辑，而是让所有人接受：**动态SQL的“动态”必须被严格限定在白名单索引层，而不是SQL语法结构层**。一旦放开表名、包名、列名的运行时自由组合，所有后续防护都形同虚设。
