EXECUTE AS 仅切换执行上下文，不授予权限；误用 EXECUTE AS OWNER 是最常见提权漏洞，因其将调用者隐式托举至 owner（如 db_owner）权限级别，应显式指定最小权限用户并手动授权其所需对象权限。
不能靠 EXECUTE AS 提升权限，只能切换执行上下文；误用 EXECUTE AS OWNER 是最常见提权漏洞来源。
EXECUTE AS 的真实作用不是“提权”，而是“固定执行身份”
SQL Server 中 EXECUTE AS 不是给调用者加权限，而是让存储过程内部语句**临时切换到另一个用户的权限上下文里运行**。这个切换发生在过程执行时，且仅对当前过程有效。关键点在于：被切换到的用户本身必须已拥有过程内所有操作所需的权限——EXECUTE AS 自己不授予权限，只启用已有权限。
-
EXECUTE AS CALLER（默认）：过程以调用者身份运行，调用者必须自己有 SELECT/INSERT 等权限 → 容易暴露底层表 -
EXECUTE AS 'username'：显式指定一个低权限账户（如proc_executor），该账户只被授予过程实际需要的几张表的几项操作权限 -
EXECUTE AS OWNER：危险！OWNER 往往是db_owner或dbo，等于把调用者“托举”到高权限角色 → 任意能执行该过程的用户都可删表、读系统视图 -
EXECUTE AS SELF：绑定创建者账号，换人维护后权限失效或漂移，不可审计
正确配置 EXECUTE AS 的三步实操
目标是让普通用户只拥有 EXECUTE 权限，却能安全运行需访问敏感表的过程。必须手动配齐被切换账户的最小权限链。
- 先创建专用执行账户：
CREATE USER proc_executor WITHOUT LOGIN; - 再授予该账户过程内真实用到的权限，例如：
GRANT SELECT ON OBJECT::Sales.Orders TO proc_executor;、GRANT UPDATE(status) ON OBJECT::Sales.Orders TO proc_executor; - 最后在创建过程时指定：
CREATE PROCEDURE Sales.uspUpdateOrderStatus ... WITH EXECUTE AS 'proc_executor';
注意：如果过程里还调用了其他存储过程或函数，那些对象也必须由 proc_executor 拥有，或显式授权给它——否则所有权链断裂，权限检查会回退到调用者。
跨数据库或跨 schema 访问时的权限断裂风险
哪怕 EXECUTE AS 'proc_executor' 配置正确，只要过程里出现跨库查询（比如 SELECT * FROM OtherDB.dbo.Config），SQL Server 就不会自动延续所有权链。此时必须单独为 proc_executor 授予目标库中的对应权限：
- 目标库需开启
TRUSTWORTHY OFF（默认值，不建议开） - 执行：
USE OtherDB; GRANT SELECT ON OBJECT::dbo.Config TO proc_executor; - 若引用未带 schema 的对象（如写成
SELECT * FROM Config），且调用者 session 的default_schema被篡改，可能命中恶意同名对象 → 必须显式写成dbo.Config
为什么你看到的 EXECUTE AS OWNER 示例都不可直接套用
文档里大量使用 EXECUTE AS OWNER 是为了演示语法简洁性，但生产环境几乎从不这么用。因为 OWNER 是动态绑定的：如果过程属于 dbo 架构，而 dbo 用户恰好是 db_owner 角色成员，那任何执行该过程的用户就等价于拥有了 db_owner 权限。这种隐式提权极难审计，且一旦数据库迁移或架构变更，权限边界立刻失控。真正可控的只有显式指定用户名 + 手动收敛其权限范围。
