如何防御SQL视图信息泄露_限制可见列与权限管控

视图安全需三层控制：定义层必须显式列字段禁用SELECT*，权限层须单独授予视图SELECT权限，元数据层须限制INFORMATION_SCHEMA等系统表访问，缺一不可。

很多人以为创建了视图就万事大吉，其实不然。视图本身并不会自动隐藏敏感列，你必须显式地写出字段名；同时，视图的权限也不从基表继承，必须单独授予——这两点如果没做到，那这个视图基本等于没设防。

视图定义必须显式列出字段，禁用 *

用 SELECT * 来创建视图，是列级信息泄露的典型起点。你想想看，哪怕基表后来只新增了一列 password_hash，视图也会立刻将其暴露无遗。用户只需要执行一句 SELECT * FROM my_view，就能轻松拿到这个敏感字段。

• 正确写法：SELECT user_id, username, created_at FROM users
• 错误写法：SELECT * FROM users（开发时是省事了，上线后可能就出事了）
• 这里有个细节需要注意：MySQL 8.0+ 和 PostgreSQL 都支持这种动态星号写法，但 SQL Server 的视图不会随基表自动更新。这意味着，一旦改了基表结构，你必须手动执行 ALTER VIEW，否则视图可能报错或返回空值。

视图权限必须显式 GRANT SELECT，不能依赖基表权限

这是一个常见的认知误区：用户有基表的 SELECT 权限，不等于就能查视图；反过来，用户没有基表权限，也不等于不能查视图。视图的权限是独立生效的。

• MySQL 授权：执行 GRANT SELECT ON my_user_view TO 'analyst'@'%'
• PostgreSQL 授权：执行 GRANT SELECT ON my_user_view TO analyst
• 常见错误：只给 users 表授权了，却忘了给视图单独授权，结果用户查询时报 permission denied for relation users（PostgreSQL）或类似的拒绝提示。
• PostgreSQL 的权限机制更灵活一些。默认情况下，视图会以调用者的身份执行权限检查（SECURITY INVOKER）。如果你想让它以创建者的身份执行，从而绕过调用者对基表的权限限制，就需要显式设置 CREATE VIEW ... WITH (security_invoker = false)，或者在创建后用 ALTER VIEW ... SET (security_invoker = false) 来修改。

别让视图定义本身变成信息源

这一点往往被忽视。攻击者只要能查询 INFORMATION_SCHEMA.VIEWS 或调用 pg_get_viewdef() 这类函数，就能直接看到视图的完整定义。这意味着，你精心设计的字段列表、用于脱敏的 CASE WHEN 逻辑，甚至背后隐藏的敏感字段名，都可能一览无余。

• MySQL：执行 REVOKE SELECT ON INFORMATION_SCHEMA.VIEWS FROM 'app_user'@'%'（这个权限默认是开放的，需要特别注意）
• PostgreSQL：执行 REVOKE SELECT ON pg_views FROM app_user，并确保 app_user 不在拥有 pg_read_all_data 权限的角色中。
• 生产环境：务必禁用普通账号的 SHOW CREATE VIEW 权限。哪怕这个账号只有 SELECT 权限，这个命令也会直接返回完整的视图定义。
• 还有更隐蔽的风险：如果你在视图里用了自定义函数做脱敏处理，那么函数体本身也可能被查询（例如通过 pg_get_functiondef()）。更要命的是，如果这个函数内部又去查询了别的配置表，那风险链就被进一步拉长了。

元数据访问必须掐断，否则视图再严也白搭

这是最后一道，也是至关重要的一道防线。只要用户能查询 INFORMATION_SCHEMA.TABLES 或 pg_tables 这类系统表，他就能枚举出数据库里所有的表和列。有了这份“地图”，攻击者就可以有针对性地构造查询，轻松绕过视图的限制。

• MySQL 8.0.29+：可以在配置文件 my.cnf 中加入 skip-show-databases 参数。这样，非超级用户执行 SHOW DATABASES 时将返回空结果。
• PostgreSQL：关键一步是执行 REVOKE USAGE ON SCHEMA pg_catalog FROM app_user。如果不这么做，用户依然可以执行 SELECT * FROM pg_catalog.pg_tables。
• SQL Server：要避免误授 VIEW DEFINITION 这类权限，普通账号绝不应该属于 db_owner 或 sysadmin 这类高权限角色。
• 值得注意的是，在 MySQL 中回收 information_schema 的权限需要显式执行 REVOKE。但在部分旧版本中，这可能不生效，这时候就需要依靠关闭元数据访问开关来兜底。

说到底，视图安全最容易被忽略的真相是：它绝非“建完就完”的一次性操作。一个真正安全的视图，依赖于三层控制的紧密配合——定义层（字段必须显式写）、权限层（视图必须单独授权）、元数据层（彻底堵死 schema 查询路径）。这三层，少了任何一层，攻击者都能找到缝隙，从视图之外将你的防御打穿。