存储过程权限绕过：当“执行”成为特洛伊木马
在数据库安全领域，一个常见的认知误区是：授予用户存储过程的EXECUTE权限，就等于构建了一道安全的访问隔离墙。然而，现实往往比想象更复杂。存储过程权限绕过的本质，根植于不同数据库引擎对执行上下文与权限继承机制的差异化设计。
简单来说：SQL Server的动态SQL默认在调用者上下文中运行；PostgreSQL需要显式设置SECURITY INVOKER；MySQL默认采用定义者（DEFINER）模式且不校验内部语句权限；而Oracle的包体权限则直接绑定到定义者账号。
这意味着，一句简单的授权背后，可能隐藏着一条通往核心数据的“秘密通道”。问题的关键从来不是配置疏忽，而是权限模型本身固有的“信任传递”特性。下面，我们就来拆解四大主流数据库中的典型场景与应对策略。
SQL Server：动态SQL的“权限隐身衣”
直接给结论：EXECUTE权限本身并不隔离数据访问。一旦存储过程中混入了动态SQL或使用了EXECUTE AS子句，调用者就可能借此间接读写本不该接触的表。
典型的错误现象是什么？系统没有抛出类似The SELECT permission was denied on the object ‘Orders‘的明确错误，但用户却成功查出了订单表的数据。或者，DBA明明只授予了EXECUTE权限，用户却能通过sp_executesql向敏感表插入记录。
- 检查动态执行：首要任务是排查存储过程是否包含
EXEC(@sql)或sp_executesql。这类代码默认在调用者上下文中运行，其权限继承自调用者，而非存储过程的定义者。 - 警惕上下文切换：如果过程中使用了
EXECUTE AS OWNER甚至EXECUTE AS ‘sa‘，就等于将高权限账户的能力临时“出借”了。调用者在此期间能做什么，完全取决于这个被模拟的账户拥有什么权限。 - 避免硬编码拼接：切忌在存储过程中将硬编码的表名直接拼接入动态SQL字符串，这会使权限校验完全失效。一个更安全的做法是，利用
sys.dm_exec_describe_first_result_set（仅限SQL Server 2012及以上版本）对元数据进行预检。
PostgreSQL：函数安全取决于一个开关
PostgreSQL的函数权限边界相对清晰，但恰恰因此更容易“踩坑”。其函数默认以定义者（SECURITY DEFINER）或调用者（SECURITY INVOKER）身份运行——这个看似简单的开关，决定了权限检查的边界在哪里。可以说，90%的越权问题都源于这个开关设置错误。
设想一个典型场景：一个Web应用账号app_user需要调用get_user_profile()函数，但绝不允许它直接查询底层的users表。
- 显式声明是关键：创建函数时，必须显式声明
SECURITY INVOKER。否则，函数将默认以SECURITY DEFINER执行，其权限等同于函数的创建者（通常是高权限的postgres用户）。 - 最小化授权：只授予
app_user执行该函数的权限：GRANT EXECUTE ON FUNCTION get_user_profile() TO app_user; - 内部权限需独立：在
SECURITY INVOKER模式下，函数体内的每一个表操作（SELECT/UPDATE）都会校验app_user是否拥有对应权限。因此，即使表只在函数内部使用，也必须单独授权：GRANT SELECT ON users TO app_user。 - 明确对象路径：不要依赖
search_path来隐式解析表名。务必使用完整的模式限定名，如public.users，以防止因Schema权限混乱导致的意外访问。
MySQL：失效的“内部校验”
MySQL的存储过程权限控制机制最易让人产生误判。其核心特点是：不校验过程内部语句的对象权限，只校验调用者“能否执行该过程”本身。换句话说，一旦拥有了EXECUTE权限，就如同拿到了一把万能钥匙，过程里即便写了DROP TABLE mysql.user这样的危险语句，也不会在授权阶段被阻拦（当然，执行时可能因缺乏SUPER权限而失败，但错误类型已非权限拒绝）。
典型表现是：用户明明没有对某张表的SELECT权限，却能通过一个存储过程轻松查出其中所有数据。DBA检查SHOW GRANTS FOR ‘u‘@‘%‘时，授权列表看起来干净整洁，殊不知风险早已埋藏在过程体内部。
- 理解安全模型：MySQL 8.0+开始支持
SQL SECURITY DEFINER/INVOKER语法，但默认是DEFINER。关键在于，DEFINER指定的用户必须真实存在，且拥有过程内部所有DML语句所需的对象权限。切勿使用不存在的用户（如‘admin‘@‘localhost‘）作为定义者。 - 定义者即最小权限账号：过程内所有操作所需的权限，都基于定义者账号进行判断，而非调用者。因此，定义者账号本身就应该是一个遵循最小权限原则的专用账号，而不是
root。 - 注意复制环境配置：在主从复制环境中，应避免启用
log_bin_trust_function_creators=ON。这个设置虽然方便，但会导致创建函数时不严格校验DETERMINISTIC等属性，可能引发复制链路中断。
Oracle PL/SQL：包级权限的收敛挑战
Oracle的包（Package）提供了强大的代码封装能力，但其权限粒度控制也因此变得更为复杂。你可以对包头（Spec）授予EXECUTE权限，但包体（Body）内的私有过程、游标、变量等，完全没有独立的权限控制机制。这意味着，一旦用户获得了包的执行权，整个包体的逻辑都将在其上下文中运行。
一个极易被忽略的细节是：在包中使用AUTHID CURRENT_USER并不等同于绝对安全。它只是将权限检查推迟到运行时；如果包体内使用了EXECUTE IMMEDIATE执行动态SQL，这些语句依然会按照调用者的权限来执行。
- 强制定义者模式：所有包都应显式声明为
AUTHID DEFINER（这也是默认值）。并确保这个定义者账号仅拥有该包运行所必需的最小表权限，且该账号应禁止用于交互式登录。 - 杜绝拼接，使用绑定：严格避免在包内构造基于用户输入拼接的SQL字符串。应改用绑定变量结合
DBMS_SQL进行预编译，这至少能阻断绝大部分的SQL注入路径。 - 定期审计实际权限：不要完全信任初始化脚本中的权限声明。应定期执行类似
SELECT * FROM USER_TAB_PRIVS WHERE TABLE_NAME = ‘T‘的查询，审计定义者账号实际持有的表权限，确保没有冗余授权。
说到底，数据库权限管理的真正难点，往往不在于“如何添加权限”，而在于“如何证明没有多给权限”。同一句GRANT EXECUTE，在SQL Server、PostgreSQL、MySQL和Oracle下触发的底层校验链路截然不同。依赖直觉或跨数据库的经验移植，很容易留下安全盲区。最终的黄金法则永远是：审视执行计划，看清实际的执行上下文，让每一条权限的授予都有迹可循、有据可依。
