ASP.NET SQL注入进阶审计：ORM、存储过程与动态查询的隐蔽风险

1. 项目概述与核心价值

最近在复盘几个老项目的安全审计报告，发现一个挺有意思的现象：很多团队在初次接触ASP.NET代码审计时，都能快速识别出那些明显的、使用字符串拼接的SQL注入点，比如string sql = "SELECT * FROM Users WHERE Name = '" + userName + "'"。但当项目稍微复杂一点，用了Entity Framework、Dapper或者一些ORM框架，甚至是一些看似“安全”的写法时，漏洞就藏得深了。我自己带团队做渗透测试和代码审计这些年，发现ASP.NET生态下的SQL注入，尤其是那些“进阶”场景，是很多中级开发者甚至部分安全人员容易忽略的盲区。这篇内容，我们就抛开那些基础的“拼接即漏洞”的常识，深入ASP.NET的肌理，看看SQL注入在那些看似坚固的防线背后，是如何悄然发生的。

这篇内容适合谁呢？如果你是ASP.NET的后端开发，正在为自己的代码安全性犯愁，或者你是初入安全领域的工程师，想了解如何在真实的、复杂的.NET项目中系统性地挖掘SQL注入漏洞，那么这里面的思路和案例会给你不少启发。我们不止讲“是什么”和“怎么防”，更重点拆解“为什么这里不安全”以及“攻击者会怎么想”，让你能从攻击者的视角来审视自己的代码。毕竟，最好的防御就是理解进攻。

2. ORM框架使用不当：你以为的安全并非绝对安全

很多开发者认为，只要用了Entity Framework (EF) Core或者Dapper这类ORM/微ORM，SQL注入就与自己无关了。这种想法非常危险，它制造了一种虚假的安全感。ORM框架确实通过参数化查询在默认情况下提供了强大的防护，但这绝不意味着你可以高枕无忧。不当的使用方式，会亲手绕过这些安全机制，重新打开危险的大门。

2.1 Entity Framework Core中的Raw SQL方法与字符串拼接

EF Core提供了执行原始SQL的强大能力，主要方法有FromSqlRaw/FromSqlInterpolated和ExecuteSqlRaw/ExecuteSqlInterpolated。这里的安全边界非常清晰，但也非常容易被误用。

危险操作：在FromSqlRaw/ExecuteSqlRaw中拼接用户输入这是最经典的错误。FromSqlRaw方法期望接收一个纯SQL字符串和参数数组。如果你把用户输入直接拼接到SQL字符串里，那就完全绕过了参数化。

// 错误示例：致命漏洞！ string userName = Request.Query["user"]; // 用户可控输入 var users = context.Users .FromSqlRaw("SELECT * FROM Users WHERE UserName = '" + userName + "'") // 直接拼接！ .ToList();

攻击者只需传入user值为admin' OR '1'='1，就能构成经典的永真条件注入。FromSqlRaw不会对传入的SQL字符串做任何处理，它只是执行它。

正确做法：始终使用参数化查询FromSqlRaw的正确用法是使用参数占位符，并将用户输入作为参数对象传入。

// 正确示例：使用参数化 string userName = Request.Query["user"]; var users = context.Users .FromSqlRaw("SELECT * FROM Users WHERE UserName = {0}", userName) // {0} 是参数占位符 .ToList(); // 或者使用命名参数（EF Core 5.0+） var users = context.Users .FromSqlRaw("SELECT * FROM Users WHERE UserName = @p0", userName) .ToList();

在这个正确示例中，EF Core会将{0}或@p0替换为一个真正的SQL参数（如@p0），并将userName变量的值作为参数值传递进去，数据库会对其进行严格的字面值处理，从而免疫注入。

关于FromSqlInterpolated的陷阱C#的字符串插值语法（$””）让代码更简洁，EF Core也提供了FromSqlInterpolated方法来支持它。关键点在于：你必须调用FromSqlInterpolated方法，而不是在FromSqlRaw中使用插值字符串！

// 错误示例：在FromSqlRaw中使用字符串插值，仍然是拼接！ string userName = Request.Query["user"]; var users = context.Users .FromSqlRaw($"SELECT * FROM Users WHERE UserName = '{userName}'") // 插值发生在方法调用前，本质还是拼接！ .ToList(); // 正确示例：使用专用的FromSqlInterpolated方法 string userName = Request.Query["user"]; var users = context.Users .FromSqlInterpolated($"SELECT * FROM Users WHERE UserName = {userName}") // 正确！ .ToList();

FromSqlInterpolated方法内部会解析这个插值字符串，将插值部分（{userName}）自动转换为参数化查询。如果你错误地在FromSqlRaw中传入一个已经插值好的字符串，那么插值过程在方法外已完成，生成的依然是一个拼接了用户输入的字符串，漏洞依旧存在。

实操心得：团队内部可以建立一条代码规范：禁止在任何FromSqlRaw或ExecuteSqlRaw的方法参数中直接使用字符串连接（+）或字符串插值（$””）。所有动态值必须通过参数数组传递。对于查询，优先考虑使用FromSqlInterpolated，并配合代码审查工具（如SonarQube）设置相应规则进行扫描。

2.2 Dapper的参数化与“IN”从句难题

Dapper以其高性能和灵活性著称，它默认也要求参数化查询，安全性很好。基本的安全用法大家应该都懂：

using var connection = new SqlConnection(connectionString); string userName = Request.Query["user"]; var users = connection.Query<User>( "SELECT * FROM Users WHERE UserName = @UserName", new { UserName = userName } // 匿名对象传参，安全 );

问题出现在一些复杂查询场景，比如动态构建“IN”从句。假设我们需要根据用户提供的一组ID来查询记录。

错误做法：动态拼接IN列表

string ids = Request.Query["ids"]; // 例如 “1,2,3” var idList = ids.Split(',').Select(int.Parse).ToList(); // 错误：在应用程序层拼接SQL片段 string sql = $"SELECT * FROM Products WHERE Id IN ({string.Join(",", idList)})"; var products = connection.Query<Product>(sql);

如果ids参数来自不可信源（即使当前是int转换），理论上似乎安全，但破坏了参数化查询的模型，且如果未来需求变化，ids可能包含其他字符，隐患就埋下了。更危险的是，如果拼接的是字符串ID，风险立现。

解决方案：使用Dapper的动态参数或工具方法Dapper本身不支持直接将数组传递给IN从句。我们需要一点技巧。

方案一：手动构建参数（适用于参数数量已知或较少）

var idList = new List<int> { 1, 2, 3 }; var parameters = new DynamicParameters(); var sql = "SELECT * FROM Products WHERE Id IN ("; for (int i = 0; i < idList.Count; i++) { var paramName = $"@id{i}"; sql += paramName; parameters.Add(paramName, idList[i]); if (i < idList.Count - 1) sql += ","; } sql += ")"; var products = connection.Query<Product>(sql, parameters);

这个方法安全，但代码繁琐。

方案二：使用像“Dapper.SqlBuilder”或“Dapper.Contrib”等社区扩展库，或者自己编写一个帮助函数来生成动态的IN从句和参数。

方案三（针对SQL Server）：使用表值参数（TVP）这是更高级但也更规范的方法，尤其适合列表项很多的情况。你需要在数据库中先定义一个表类型，然后在C#中传递DataTable作为参数。

注意事项：处理动态SQL时，尤其是IN从句、ORDER BY字段名、表名等，必须将用户输入视为“数据”而非“代码”。对于字段名、表名，应该使用白名单机制进行校验。例如，判断orderBy参数是否在[“Id”, “Name”, “CreateTime”]这个允许的列表内，而不是直接拼接到SQL中。

3. 看似安全的“存储过程”与“参数化”误区

“我们用存储过程，所以没有SQL注入。” 这是我听过最危险的误解之一。存储过程本身只是一段存储在数据库中的SQL代码，它是否安全，完全取决于调用它的方式。

3.1 动态SQL在存储过程内部

如果存储过程内部使用了EXEC或sp_executesql来执行动态拼接的SQL，而拼接的源是存储过程的输入参数，那么注入点就从应用层转移到了数据库层。

假设一个存储过程如下：

CREATE PROCEDURE GetUserData @UserName NVARCHAR(100) AS BEGIN DECLARE @sql NVARCHAR(MAX); SET @sql = N'SELECT * FROM Users WHERE UserName = ''' + @UserName + N''''; EXEC sp_executesql @sql; -- 危险！在数据库内部进行了字符串拼接 END

在ASP.NET中，即使用参数化方式调用这个存储过程，也是不安全的：

using var command = new SqlCommand("GetUserData", connection); command.CommandType = CommandType.StoredProcedure; command.Parameters.AddWithValue("@UserName", userInput); // 看似参数化 // 但存储过程内部拼接了，所以注入依然会发生

攻击者传入@UserName为admin' OR '1'='1，最终在数据库内部执行的SQL就是SELECT * FROM Users WHERE UserName = 'admin' OR '1'='1'。

审计要点：在代码审计中，如果看到项目调用了存储过程，不能就此放过。需要追溯存储过程的定义，检查其内部是否含有动态SQL拼接。对于重要的存储过程，应纳入代码审计范围。

3.2 错误的参数化使用：AddWithValue的陷阱

SqlParameterCollection.AddWithValue方法用起来很方便，但它有一个潜在的陷阱：它根据传入的C#值来推断SQL数据库类型。如果推断的类型和数据库表字段的实际类型不匹配，在某些边缘情况下可能导致问题，虽然不直接导致注入，但可能引发性能问题或隐式转换错误，间接影响安全。

更推荐的做法是显式指定参数的类型、大小和方向。

// 更好的做法 var param = new SqlParameter("@UserName", SqlDbType.NVarChar, 100); param.Value = userName; command.Parameters.Add(param);

对于字符串类型，指定大小（如NVarChar(100)）很重要。如果不指定，对于AddWithValue，它可能会创建一个很大的参数（如NVarChar(4000)或更大），这可能导致查询计划无法优化，以及潜在的内存浪费。

4. LINQ to SQL与动态查询构造的盲点

LINQ to SQL和Entity Framework的LINQ查询通常能生成参数化SQL，非常安全。但动态构建查询表达式树（Expression Tree）时，如果处理不当，也可能引入风险。

4.1 动态构建Expression时的字符串拼接

有时我们需要根据条件动态构建Where从句。错误的方式是直接将用户输入作为字符串用于表达式树的比较。

// 危险示例：动态构建表达式树时拼接字符串 string propertyName = Request.Query["sortBy"]; // 例如 “UserName” string filterValue = Request.Query["filter"]; // 用户输入 var parameter = Expression.Parameter(typeof(User), "u"); // 错误：将filterValue直接用于构建等于表达式 var property = Expression.Property(parameter, propertyName); var constant = Expression.Constant(filterValue); // 注意：这里Constant的值是用户输入的字符串 var equalExpression = Expression.Equal(property, constant); var lambda = Expression.Lambda<Func<User, bool>>(equalExpression, parameter); var query = context.Users.Where(lambda);

在这个例子中，filterValue作为Expression.Constant的值，最终会被转换为SQL参数，看起来是安全的。真正的风险在于propertyName，它被直接用于Expression.Property。如果propertyName来自用户输入，攻击者可以传入一个不存在的属性名导致运行时错误（反射攻击），或者在某些更复杂的动态构造场景中，可能被利用。

安全做法：对于属性名（字段名）、排序方向等，必须进行白名单校验。

// 安全做法：白名单校验属性名 var allowedProperties = new HashSet<string> { "Id", "UserName", "Email" }; if (!allowedProperties.Contains(propertyName)) { throw new ArgumentException("Invalid property name."); } // ... 然后再构建表达式树

对于filterValue，因为它最终成了Constant表达式的值，EF Core会将其作为参数处理，所以针对这个值的SQL注入风险是低的。但业务逻辑校验（如长度、格式）仍需进行。

4.2 使用第三方动态LINQ库的风险

有些开发者为了更灵活，会使用像System.Linq.Dynamic.Core这样的库，它允许你用字符串的形式书写LINQ的Where或OrderBy从句。

using System.Linq.Dynamic.Core; string filter = Request.Query["filter"]; // 例如 “UserName == \"admin\"” var query = context.Users.Where(filter);

这是极高风险的行为！System.Linq.Dynamic.Core等库在解析字符串时，可能会直接或间接地将其转换为表达式树并最终生成SQL。如果这个过滤字符串完全由用户控制，就相当于给了用户一个直接编写部分查询逻辑的能力，可能导致注入或逻辑绕过。除非你能绝对保证这个字符串的来源和内容是完全可信的（比如来自内部配置），否则应避免使用。

如果必须使用，应对输入进行严格的语法限制和白名单过滤，或者仅允许在高度受控的内部管理界面使用。

5. 二次编码与宽字节注入等“古老”但存在的陷阱

在ASP.NET中，由于框架本身和现代SQL客户端驱动（如SqlClient）的防护，一些经典的注入技巧（如宽字节注入）已经很难直接利用。但审计时仍需保持警惕，特别是当应用程序在处理输入时进行了不规范的编码转换，或者与老旧数据库交互时。

5.1 不规范的输入解码

假设一个场景：应用程序为了“安全”，对用户输入先进行了一次HTML编码或URL编码，然后在拼接SQL前又进行了一次解码。

string userInput = Server.UrlDecode(Request.Query["user"]); // 第一次解码 // ... 一些业务逻辑 ... string sql = "SELECT * FROM Users WHERE Name = '" + userInput + "'"; // 拼接

如果攻击者提交的参数是user=%27%20OR%20%271%27%3D%271（即' OR '1'='1的URL编码），经过UrlDecode后，还原成了注入载荷。这种“画蛇添足”的编码/解码操作，有时会因为开发者的误解而引入风险。关键点在于：防御应该在查询参数化时进行，而不是依赖对输入字符串的预处理。参数化查询机制会正确处理各种字符。

5.2 警惕“万能密码”查询的变种

在一些古老的或设计不良的登录逻辑中，仍然能看到这样的代码：

string sql = "SELECT COUNT(*) FROM Users WHERE UserName = @UserName AND Password = @Password"; var count = connection.ExecuteScalar<int>(sql, new { UserName = name, Password = pass }); if (count > 0) { // 登录成功 }

这看起来是参数化，是安全的。但如果后端密码校验不是比较哈希值，而是比较明文（这本身是严重安全问题），并且SQL语句构造不当，则可能存在问题。更关键的是，如果整个查询的逻辑是动态拼接的，比如根据多个可选条件构建WHERE从句，就很容易在拼接条件时出错。

审计建议：重点关注所有SQL语句的构建点，尤其是那些根据条件动态添加AND、OR从句的代码。确保每一个动态添加的条件都使用了参数，并且条件逻辑运算符（AND/OR）是代码固定的，而不是来自用户输入。

6. 自动化审计辅助与手动验证结合

对于大型项目，完全依赖人工审计效率低下。我们需要借助工具进行初步扫描，但绝不能完全信任工具。

6.1 使用静态应用程序安全测试（SAST）工具

工具如SonarQube、Visual Studio 内置的代码分析、Security Code Scan等，可以集成到CI/CD流水线中。

• SonarQube：配置好C#规则集（如csharpsquid:S3649,csharpsquid:S2077等），它可以识别FromSqlRaw中的字符串拼接、SqlCommand的拼接等常见模式。
• Security Code Scan：这是一个专门针对.NET的安全扫描器，能检测SQL注入、XSS、CSRF等多种漏洞，对ASP.NET MVC/Web API的支持很好。

工具的优点是覆盖全、速度快，能发现明显的漏洞模式。缺点是误报和漏报。它无法理解复杂的业务逻辑，比如一个字符串变量虽然经过了拼接，但它的值完全来自内部安全的源（如配置文件常量），工具可能会误报。反之，一些通过复杂数据流传递的、间接的注入点，工具可能发现不了。

6.2 人工审计的关键步骤与思维

工具扫完后，人工审计需要聚焦于高风险区域和工具的盲区：

1. 入口点追踪：从所有用户可控的输入点（Request.Query、Request.Form、Request.Headers、Route Data、Cookie）开始，跟踪数据流。看这些数据最终流向了哪里？是否进入了数据库查询的构建环节？
2. 重点关注“字符串”操作：在数据流路径上，寻找任何与SQL关键字（SELECT,INSERT,UPDATE,DELETE,WHERE,FROM,UNION,EXEC,sp_等）相关的字符串操作（+,$,String.Format,StringBuilder.Append,Regex.Replace等）。这些地方是潜在的“代码”与“数据”混合区。
3. 审查数据库调用上下文：找到所有使用SqlCommand、Dapper查询方法、EF Core的FromSqlRaw/ExecuteSqlRaw、DbContext.Database.ExecuteSqlCommand等的地方。仔细检查传入的SQL字符串是如何构建的。
4. 理解业务逻辑：有些注入点非常隐蔽。例如，一个查询先根据用户ID查出某个“模板SQL”存储在数据库里，然后再用当前用户的其他输入来执行这个“模板SQL”。这相当于二次注入，非常危险。人工审计需要理解这类业务逻辑。
5. 验证存储过程和函数：如果项目大量使用存储过程，需要抽样审查关键存储过程的源代码，检查内部是否有EXEC(@sql)的动态执行。

6.3 常见问题排查技巧实录

在实际审计和渗透测试中，我们经常会遇到一些疑点，以下是一些排查思路：

• 现象：工具报告了一个在StringBuilder中的潜在SQL注入漏洞，但该StringBuilder最终的内容是用于生成日志或显示在前端。
  • 排查：确认数据流的最终目的地。如果只是用于日志或输出到HTML（需注意XSS），则不构成SQL注入。但需要检查是否有其他地方引用了这个字符串。
• 现象：一个查询参数来自ConfigurationManager.AppSettings或环境变量。
  • 排查：通常认为是可信源。但需要确认该配置项是否可能被外部篡改（如通过部署脚本、配置管理界面）。如果绝对可信，可标记为低风险。
• 现象：代码中使用了SqlParameter，但参数值是通过字符串拼接的方式计算出来的。
  • 排查：例如new SqlParameter("@id", userId + "abc")。这里userId如果是数字，拼接后作为整体字符串传给@id参数，由于是参数化，userId中的特殊字符会被转义，所以userId本身无法注入。但需要评估userId的来源和业务逻辑是否正确。
• 现象：在ORDER BY子句中使用动态字段名。
  • 排查：这是一个典型的风险点。ORDER BY后面不能直接使用参数化变量（因为它是标识符，不是值）。必须使用白名单机制。审计时检查是否有对sortBy这类参数进行白名单校验。

速查表：ASP.NET SQL注入审计重点清单

7. 防御策略纵深构建

找到漏洞是为了修复它。修复不仅仅是把一处拼接改成参数化，而是要在团队和项目中建立纵深防御体系。

1. 编码规范与强制培训：将“禁止在SQL语句中拼接用户输入”作为一条铁律写入团队编码规范。对新成员进行强制性的安全编码培训。
2. 代码审查（Code Review）：在Pull Request中，将SQL查询构建作为重点审查项。利用Git的钩子或集成工具，在提交时触发简单的脚本检查是否有明显的字符串拼接模式。
3. SAST工具集成：将SonarQube或Security Code Scan集成到持续集成（CI）流程中，设置质量阈，如果发现新的中高危SQL注入漏洞，则构建失败。
4. 使用ORM的最佳实践：
   • EF Core：优先使用LINQ查询。必须使用原始SQL时，只用FromSqlInterpolated或正确参数化的FromSqlRaw。
   • Dapper：坚持对所有查询使用参数对象。
   • 避免在数据库层拼接：严禁在存储过程、函数、触发器中通过拼接构建动态SQL。如果必须使用，需经过严格的安全评审。
5. 输入验证与输出编码：虽然参数化查询是解决SQL注入的根本，但输入验证（长度、格式、类型、业务规则）和输出编码（防止XSS）是良好的安全卫生习惯，能抵御其他类型的攻击。
6. 最小权限原则：连接数据库的应用程序账户，不应具有db_owner或sa等高级权限。根据业务需要，授予其最小的、必要的权限（如仅能执行特定存储过程，或对特定表只有SELECT、INSERT权限），这样即使发生注入，也能限制攻击者造成的破坏范围。

审计ASP.NET项目的SQL注入，是一个从“信任边界”出发，追踪“数据流”，识别“代码与数据混合点”的过程。它要求审计者既熟悉ASP.NET和C#的各种数据库访问技术，又能像攻击者一样思考，去琢磨那些看似正常的代码背后是否隐藏着逻辑裂缝。记住，没有一劳永逸的银弹，安全是一个持续的过程。每次代码提交、每次架构变更，都需要重新用审慎的眼光去评估其中的安全风险。