含绑定变量的动态SQL存储过程写法能否防范SQL注入？

咱们直接说结论：你这种写法能防护一部分SQL注入，但存在明显的风险漏洞，得拆开来分析：

安全的部分 #

你用OPEN CURSOR ... USING <bind variable>来传递p_asof参数的做法是完全安全的。绑定变量的核心作用就是把参数值和SQL语句本身做语法层面的隔离，数据库会先解析SQL结构，再代入参数值，攻击者没法通过篡改p_asof的值来破坏原SQL的逻辑，这部分完全没问题。

有风险的部分 #

问题出在p_select_statement这个参数上——它是直接传入的完整SQL片段（或者半完整的），属于动态拼接的未校验内容。如果这个参数的来源不可信（比如来自用户输入、外部系统接口传参），攻击者可以构造恶意的SQL字符串传入，比如把p_select_statement改成：

'select * from table where lastModifiedTime > :p_asof; drop table your_important_table;'

一旦存储过程执行这个动态SQL，就会触发恶意操作，直接破坏数据库。

结合你的场景的优化建议 #

你之所以用这种写法，是为了固定返回列的顺序（避免select *的列顺序不可控），其实可以换更安全的实现方式：

方案1：固定列头，只传入条件片段 #

不要把整个SQL作为参数，而是在存储过程里写死固定的列顺序，只允许传入可变的<conditions>部分：

PROCEDURE getByFilter ( p_conditions IN VARCHAR2, p_asof IN TIMESTAMP, p_cur OUT SYS_REFCURSOR )
IS
    v_dynamic_sql VARCHAR2(4000);
BEGIN
    -- 固定列顺序，只拼接条件部分
    v_dynamic_sql := 'SELECT col1, col2, col3 FROM table WHERE lastModifiedTime > :p_asof ' || p_conditions;
    OPEN p_cur FOR v_dynamic_sql USING p_asof;
END;

不过要注意：如果p_conditions还是来自不可信来源，依然有注入风险，所以最好搭配下面的方案。

方案2：用白名单+拆分参数的方式 #

把可变条件拆成「列名、操作符、值」三个独立参数，然后在存储过程里做白名单校验，只允许合法的列名和操作符：

PROCEDURE getByFilter ( p_col IN VARCHAR2, p_op IN VARCHAR2, p_val IN VARCHAR2, p_asof IN TIMESTAMP, p_cur OUT SYS_REFCURSOR )
IS
    v_dynamic_sql VARCHAR2(4000);
BEGIN
    -- 白名单校验：只允许指定的列和操作符
    IF p_col NOT IN ('col1', 'col2', 'col3') OR p_op NOT IN ('=', '>', '<', 'LIKE') THEN
        RAISE_APPLICATION_ERROR(-20001, 'Invalid column or operator');
    END IF;
    -- 安全拼接SQL，值依然用绑定变量
    v_dynamic_sql := 'SELECT col1, col2, col3 FROM table WHERE lastModifiedTime > :p_asof AND ' || p_col || ' ' || p_op || ' :p_val';
    OPEN p_cur FOR v_dynamic_sql USING p_asof, p_val;
END;

这种方式既保证了列顺序固定，又把注入风险降到了最低。

方案3：必须传入完整SQL的情况 #

如果业务上一定要传入完整的p_select_statement，那你必须严格确保这个参数的来源是完全可信的——比如只能由后端代码生成，绝对不能接受用户输入、外部接口传参等不可信数据源。

总结 #

绑定变量的部分是安全的，但动态传入的SQL片段是最大的风险点。优先推荐用「固定列头+白名单拆分参数」的方式，既满足你固定列顺序的需求，又能有效防范SQL注入。

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