SQL Server中不存在参数化视图；视图仅是命名的SELECT语句，不接收参数，防注入需三要素：视图封装数据范围、严格账号权限控制、调用时坚持参数化查询。
SQL Server 中没有“参数化视图”这回事——视图本身不接受参数，也不能靠定义视图来防注入。真正起作用的是：用视图封装数据范围 + 限制账号权限 + 调用时坚持参数化查询。漏掉任意一环，风险照旧。
SQL Server 视图根本不能带参数
你写 CREATE VIEW v_user AS SELECT id, name FROM users，然后想在查询里传参比如 SELECT * FROM v_user WHERE id = @id —— 这没问题，但这里的 @id 是外部查询的参数，和视图定义毫无关系。视图只是个命名的 SELECT 语句，它不解析、不接收、不绑定任何运行时值。所谓“参数化视图”，是常见误解。
常见错误现象：
- 以为建了视图就自动过滤了字段，结果应用层仍拼接字符串查视图：
SELECT * FROM v_user WHERE name = ' + @name - 把视图当存储过程用，期待它能校验输入或做逻辑分支
用视图缩小攻击面的实操要点
视图真正的价值是“数据可见性隔离”：让应用账号只能看到你允许它查的那一部分数据，哪怕注入成功，也拿不到敏感列或非活跃行。
- 显式列出字段，禁用
*：SELECT id, username, email FROM users WHERE status = 'active'，别让salary或last_login_ip暴露出去 - 建完视图后，立刻收回基表权限：
REVOKE SELECT ON users FROM app_user - 只授视图权限：
GRANT SELECT ON v_user TO app_user - 确认 SQL Server 不会因角色继承意外放权——必须显式
GRANT SELECT ON OBJECT::dbo.v_user，别依赖db_datareader
调用视图时仍需参数化查询
即使视图再干净、权限再严，只要应用代码还在拼字符串，注入就成立。比如 C# 里写：
string sql = "SELECT * FROM v_user WHERE username = '" + Request.Query["u"] + "'";
攻击者传 u=admin' OR 1=1 --，照样查出所有用户。
正确做法（.NET 示例）：
string sql = "SELECT * FROM v_user WHERE username = @username";<br>using var cmd = new SqlCommand(sql, conn);<br>cmd.Parameters.Add("@username", SqlDbType.NVarChar).Value = Request.Query["u"];<br>var reader = cmd.ExecuteReader();
-
@username必须走Parameters.Add()，不能拼进 SQL 字符串 - 类型要明确（如
SqlDbType.NVarChar），长度可设上限（避免 NVARCHAR(MAX) 被滥用） - ORM 如 Entity Framework 默认参数化，但小心
FromSqlRaw()或ExecuteSqlRaw()这类绕过点
嵌套视图与权限模型的坑
SQL Server 视图默认按“调用者权限”执行，即检查当前连接账号对底层表是否有 SELECT 权限。如果你忘了撤掉 app_user 对 users 表的权限，那视图形同虚设。
更麻烦的是跨库视图：如果 v_user 引用了 otherdb.dbo.audit_log，而 app_user 恰好有 otherdb 的 db_datareader，那它就能顺带查审计日志——这种隐性权限泄露很难发现。
- 务必逐库检查账号权限，别信“只给了视图权限”的直觉
- 避免跨库引用；非用不可时，用
EXECUTE AS显式限定执行上下文 - 测试阶段用低权限账号连库执行
SELECT * FROM v_user，确认报错而非返回数据
最易被忽略的一点：视图不拦布尔盲注。即使你封死了字段和权限，攻击者仍可能通过 AND 1=(SELECT COUNT(*) FROM sys.tables) 这类条件探测结构——参数化查询才是唯一能切断注入链的环节。
