防止SQL注入的PL/SQL绑定变量与游标共享

防止SQL注入最有效的PL/SQL手段，就是用绑定变量替代字符串拼接，再配合游标共享机制让数据库高效复用执行计划。说白了，你把用户输入的值当作"参数"传进去，而不是把它拼进SQL语句的文本里，数据库引擎就会把它当作数据而非可执行代码来处理，注入攻击自然失效。同时，使用绑定变量的SQL语句会触发Oracle的游标共享（Cursor Sharing），减少硬解析次数，性能和安全一举两得。

很多开发者写PL/SQL的时候习惯这样干：把用户输入直接拼到SQL字符串里，然后用EXECUTE IMMEDIATE或者DBMS_SQL去执行。这种写法不仅慢，而且是SQL注入的温床。攻击者只要在输入框里塞一段恶意SQL片段，就能篡改你的查询逻辑、窃取数据甚至删除表。解决这个问题的核心就是两个技术点：绑定变量（Bind Variables）和游标共享（Cursor Sharing）。下面我从原理到实操，一步步给你讲透。

什么是绑定变量，为什么它能防注入

绑定变量就是在SQL语句中用占位符（比如:var1、:var2）代替具体的值，然后在执行时通过USING子句或者DBMS_SQL的BIND_VARIABLE过程把实际值绑定上去。Oracle在解析这条SQL的时候，占位符的位置是固定的，用户输入的值只是被当作字面量数据填进去，不会被当作SQL语法的一部分去解析。

举个最直观的例子。假设你有一个根据员工ID查询信息的功能：

-- 危险写法：字符串拼接，存在SQL注入风险
DECLARE
  v_sql   VARCHAR2(200);
  v_emp_id VARCHAR2(20) := '1001 OR 1=1';  -- 恶意输入
  v_name  VARCHAR2(100);
BEGIN
  v_sql := 'SELECT employee_name FROM employees WHERE employee_id = ''' || v_emp_id || '''';
  EXECUTE IMMEDIATE v_sql INTO v_name;
  DBMS_OUTPUT.PUT_LINE(v_name);
END;
/

上面这段代码，如果v_emp_id被攻击者改成"1001 OR 1=1"，整个WHERE条件就变成了恒真，所有员工信息全部暴露。而用绑定变量改写后：

-- 安全写法：使用绑定变量
DECLARE
  v_sql   VARCHAR2(200);
  v_emp_id VARCHAR2(20) := '1001 OR 1=1';  -- 即使是恶意输入也安全
  v_name  VARCHAR2(100);
BEGIN
  v_sql := 'SELECT employee_name FROM employees WHERE employee_id = :emp_id';
  EXECUTE IMMEDIATE v_sql INTO v_name USING v_emp_id;
  DBMS_OUTPUT.PUT_LINE(v_name);
END;
/

在这个安全版本里，不管v_emp_id里塞什么奇怪的字符，Oracle都只会把它当成一个普通字符串去和employee_id列做等值比较。因为SQL的语法结构在解析阶段就已经确定了，后面绑定的值根本没有机会改变语法树。

PL/SQL中绑定变量的三种主要使用方式

在PL/SQL开发中，绑定变量不是只有一种写法，根据场景不同至少有三种主流方式。

第一种是EXECUTE IMMEDIATE配合USING子句，适合动态SQL场景。你构造一个带占位符的SQL字符串，然后用USING把值传进去。支持IN、OUT、IN OUT三种模式，可以绑定多个变量。

DECLARE
  v_sql VARCHAR2(500);
  v_dept_id NUMBER := 10;
  v_count   NUMBER;
BEGIN
  v_sql := 'SELECT COUNT(*) FROM employees WHERE department_id = :dept_id';
  EXECUTE IMMEDIATE v_sql INTO v_count USING v_dept_id;
  DBMS_OUTPUT.PUT_LINE('员工数: ' || v_count);
END;
/

第二种是DBMS_SQL包，适合更复杂的动态SQL场景，比如你需要在运行时动态决定查询哪些列、表名是什么。DBMS_SQL提供了BIND_VARIABLE、BIND_ARRAY等过程，可以精细控制绑定行为。

DECLARE
  v_cursor  INTEGER;
  v_sql     VARCHAR2(500);
  v_dept_id NUMBER := 20;
  v_name    VARCHAR2(100);
  v_rows    NUMBER;
BEGIN
  v_cursor := DBMS_SQL.OPEN_CURSOR;
  v_sql := 'SELECT employee_name FROM employees WHERE department_id = :dept_id';
  DBMS_SQL.PARSE(v_cursor, v_sql, DBMS_SQL.NATIVE);
  DBMS_SQL.BIND_VARIABLE(v_cursor, ':dept_id', v_dept_id);
  DBMS_SQL.DEFINE_COLUMN(v_cursor, 1, v_name, 100);
  v_rows := DBMS_SQL.EXECUTE(v_cursor);
  IF DBMS_SQL.FETCH_ROWS(v_cursor) > 0 THEN
    DBMS_SQL.COLUMN_VALUE(v_cursor, 1, v_name);
    DBMS_OUTPUT.PUT_LINE('员工: ' || v_name);
  END IF;
  DBMS_SQL.CLOSE_CURSOR(v_cursor);
END;
/

第三种是直接在静态SQL中使用，这是最简单也最推荐的方式。如果你的SQL语句结构是固定的，只是参数值变化，那就完全不需要动态SQL，直接写带绑定变量的静态语句即可。

DECLARE
  v_dept_id NUMBER := 30;
  v_name    VARCHAR2(100);
BEGIN
  SELECT employee_name INTO v_name
  FROM employees
  WHERE department_id = v_dept_id;  -- 隐式绑定变量
  DBMS_OUTPUT.PUT_LINE('员工: ' || v_name);
EXCEPTION
  WHEN NO_DATA_FOUND THEN
    DBMS_OUTPUT.PUT_LINE('未找到员工');
END;
/

注意，在静态SQL中，PL/SQL变量直接出现在WHERE条件里，Oracle会自动把它当作绑定变量处理，不需要你显式加冒号。这种写法既安全又高效，是首选方案。

游标共享是什么，为什么它和绑定变量密不可分

游标共享（Cursor Sharing）是Oracle数据库的一个重要优化机制。当你使用绑定变量时，SQL语句的文本部分是固定的，只有绑定值不同。Oracle会把这种"结构相同、值不同"的SQL归为同一个父游标（Parent Cursor），子游标（Child Cursor）之间共享执行计划，避免每次执行都重新做硬解析（Hard Parse）。

硬解析是很耗资源的操作，包括语法检查、语义分析、优化器生成执行计划等。如果你不用绑定变量，每次SQL文本都不一样（因为拼接了不同的值），Oracle就认为每条都是新SQL，每次都要硬解析。用了绑定变量之后，同一条SQL只解析一次，后续执行直接复用，性能差距可以达到几十倍甚至上百倍。

Oracle的游标共享有三个级别，通过初始化参数CURSOR_SHARING控制：

EXACT模式（默认值）：只有文本完全相同的SQL才共享游标。如果你用了绑定变量但SQL文本有细微差异（比如多了个空格），就不会共享。

FORCE模式：Oracle会尝试把所有SQL强制转换成绑定变量形式，然后共享。这对防止注入有额外好处，但可能导致某些复杂SQL的执行计划不是最优的。

SIMILAR模式：Oracle会智能判断哪些SQL适合转换，只对那些转换后不影响语义的SQL做游标共享。这是一个比较平衡的选择。

-- 查看当前游标共享设置
SHOW PARAMETER cursor_sharing;

-- 修改为SIMILAR模式（需要DBA权限）
ALTER SYSTEM SET cursor_sharing = 'SIMILAR' SCOPE=BOTH;

在实际开发中，最好的做法是自己在代码层面就写好绑定变量，不要依赖CURSOR_SHARING=FORCE来兜底。因为FORCE模式有可能把不该转换的SQL也转换了，导致逻辑错误或者性能问题。

动态SQL中如何确保游标共享最大化

动态SQL是绑定变量和游标共享最容易出问题的地方。很多人写动态SQL的时候，虽然用了绑定变量，但SQL文本本身还是有变化，导致共享失败。比如你动态拼接表名、列名，这些部分是不能用绑定变量的（Oracle不支持表名和列名作为绑定变量），但你可以把可变的过滤条件部分用绑定变量处理。

DECLARE
  v_sql     VARCHAR2(1000);
  v_dept_id NUMBER := 10;
  v_salary  NUMBER := 5000;
  v_cursor  SYS_REFCURSOR;
  v_name    VARCHAR2(100);
  v_sal     NUMBER;
BEGIN
  -- 表名和列名是动态的，但过滤条件用绑定变量
  v_sql := 'SELECT employee_name, salary FROM ' || DBMS_ASSERT.SQL_OBJECT_NAME('EMPLOYEES') ||
           ' WHERE department_id = :dept_id AND salary > :min_salary';

  OPEN v_cursor FOR v_sql USING v_dept_id, v_salary;
  LOOP
    FETCH v_cursor INTO v_name, v_sal;
    EXIT WHEN v_cursor%NOTFOUND;
    DBMS_OUTPUT.PUT_LINE(v_name || ' - ' || v_sal);
  END LOOP;
  CLOSE v_cursor;
END;
/

上面这个例子中，表名用了DBMS_ASSERT.SQL_OBJECT_NAME做了安全校验（防止SQL注入），过滤条件用了绑定变量。这样即使表名部分有变化，只要过滤条件的结构一致，Oracle仍然可以在一定程度上复用执行计划。但严格来说，表名不同的SQL还是会产生不同的父游标，这是正常的，不必强求。

除了绑定变量，还有哪些配套防护措施

绑定变量是防SQL注入的核心，但不是全部。在PL/SQL开发中，还有几个配套手段值得一起用上。

第一，输入验证和白名单。在把用户输入传给SQL之前，先在应用层做校验。比如员工ID应该是数字，就先用正则或者类型转换确认它是纯数字，不合法的直接拒绝。这叫纵深防御，即使绑定变量出了问题，还有一层保护。

DECLARE
  v_emp_id VARCHAR2(20) := '1001abc';
  v_id     NUMBER;
BEGIN
  -- 先尝试转换为数字，失败则抛异常
  v_id := TO_NUMBER(v_emp_id);
  -- 确认是合法数字后再用于查询
  SELECT employee_name INTO v_name FROM employees WHERE employee_id = v_id;
EXCEPTION
  WHEN VALUE_ERROR THEN
    DBMS_OUTPUT.PUT_LINE('输入不是有效数字');
END;
/

第二，使用DBMS_ASSERT包做SQL对象名和表达式的校验。当你需要动态拼接表名、列名、ORDER BY子句等不能用绑定变量的部分时，用DBMS_ASSERT来过滤掉危险字符。

-- 校验表名是否合法
v_table := DBMS_ASSERT.SQL_OBJECT_NAME(p_table_name);

-- 校验简单的SQL表达式（如ORDER BY列名）
v_order_by := DBMS_ASSERT.ENQUOTE_NAME(p_order_col, FALSE);

第三，最小权限原则。执行PL/SQL的数据库账号不要给DBA权限，只给必要的SELECT、INSERT、UPDATE、DELETE权限。这样即使注入成功，攻击者能做的事情也有限。最好用不同的账号分别处理查询和修改操作。

第四，开启审计。通过Oracle的审计功能记录所有对敏感表的访问，一旦发现异常查询模式可以及时告警。可以用统一审计（Unified Auditing）或者传统审计来实现。

性能视角：绑定变量与游标共享的实际收益

从性能角度看，绑定变量和游标共享带来的收益是实实在在的。我见过不少生产环境的案例，把字符串拼接改成绑定变量之后，CPU使用率下降了40%以上，SQL解析相关的等待事件几乎消失。

具体来说，硬解析一次可能消耗几毫秒到几十毫秒，看SQL复杂度。如果一个高并发系统每秒执行几千次SQL，每次都硬解析，累积下来就是巨大的浪费。而软解析（Soft Parse，也就是复用已有游标）只需要几微秒，差距是千倍级别的。

你可以通过V$SQL视图来验证游标共享的效果：

-- 查看某条SQL的执行次数和解析次数
SELECT sql_text, executions, parse_calls, 
       ROUND(parse_calls/NULLIF(executions,0)*100, 2) AS parse_ratio_pct
FROM v$sql
WHERE sql_text LIKE '%employees%'
ORDER BY executions DESC;

如果parse_calls和executions接近1:1，说明每次执行都在硬解析，绑定变量没写好。如果executions远大于parse_calls，说明游标共享生效了，性能是健康的。

常见误区和注意事项

最后说几个开发中容易踩的坑。第一，不要以为用了绑定变量就万事大吉。如果你在绑定变量之前对输入做了不当的处理（比如用REPLACE去掉单引号），攻击者可能用编码绕过。正确做法是永远不要自己做"清洗"，让绑定变量机制本身去处理。

第二，FORCE模式不是银弹。虽然它能把非绑定变量的SQL强制转换，但对于包含HINT的SQL、包含函数调用的复杂条件，转换可能失败或者产生错误的执行计划。生产环境建议用SIMILAR或者EXACT，配合代码层面的绑定变量。

第三，注意绑定变量的数据类型匹配。如果你用VARCHAR2类型的绑定变量去绑定一个NUMBER列，Oracle会做隐式转换，这可能导致索引失效。确保绑定变量的类型和目标列的类型一致。

第四，在使用DBMS_SQL时，绑定变量的名称要和SQL文本中的占位符完全一致，包括冒号。大小写在Oracle中不敏感，但拼写不能错。绑定顺序也要和SQL中出现的顺序对应。

总结一下，防止SQL注入的PL/SQL最佳实践就是：能写静态SQL就不写动态SQL，必须动态SQL就用绑定变量，配合DBMS_ASSERT做对象名校验，数据库账号遵循最小权限，同时利用游标共享机制获得性能红利。这套组合拳打下来，安全性和性能都能得到保障。

防止SQL注入的PL/SQL绑定变量与游标共享

服务指南

帮助中心