在C#开发中，使用Dapper执行内联查询时，直接拼接字符串是SQL注入攻击的主要入口。防止SQL注入的核心方法是始终使用参数化查询，即通过Dapper的DynamicParameters或匿名对象传递参数，让Dapper自动处理参数化，确保用户输入被当作数据而非可执行代码处理。这是唯一可靠的内联查询安全实践。
理解SQL注入在内联查询中的发生机制
内联查询（Inline Query）指的是在代码中直接编写SQL字符串，然后通过Dapper的Query或Execute方法执行。例如，开发人员可能为了方便，写出这样的代码：string sql = "SELECT * FROM Users WHERE Username = '" + username + "'";。如果用户输入的username是"admin' --"，那么最终的SQL语句会变成"SELECT * FROM Users WHERE Username = 'admin' --'"，"--"注释掉了后续语句，攻击者可能无需密码即可登录。更危险的输入可能包含"DROP TABLE Users"等破坏性命令。这种字符串拼接方式使得应用程序将用户输入直接解释为SQL语法的一部分，从而为攻击者打开了大门。
Dapper参数化查询是根本解决方案
Dapper本身支持参数化查询，这是防止SQL注入最有效、最推荐的方法。参数化查询确保SQL语句的结构与数据分离，数据库引擎会明确区分指令和参数值。在Dapper中，你可以使用匿名对象或DynamicParameters来传递参数。例如，对于查询"SELECT * FROM Users WHERE Username = @Username"，你可以这样执行：var user = connection.Query<User>(sql, new { Username = username });。Dapper会自动将@Username参数替换为安全的值，即使用户输入包含恶意SQL片段，也会被当作纯文本处理，不会改变原语句的逻辑。这种方法简单、高效，且是行业标准做法。
使用DynamicParameters进行复杂参数控制
对于更复杂的场景，比如动态构建查询条件，可以使用Dapper的DynamicParameters类。它允许你显式添加参数并控制细节，如数据类型、大小和方向。例如：
var parameters = new DynamicParameters();
parameters.Add("@Username", username, DbType.String);
parameters.Add("@Role", role, DbType.String, ParameterDirection.Input, 50);
var sql = "SELECT * FROM Users WHERE Username = @Username AND Role = @Role";
var users = connection.Query<User>(sql, parameters);DynamicParameters特别适用于参数较多或需要精细控制的场合，它同样保证了参数化安全。注意，即使使用DynamicParameters，也不要在SQL字符串中拼接条件（如"WHERE 1=1"后接字符串），而应使用条件逻辑构建安全的SQL和参数列表。
避免内联查询中的常见错误模式
一些开发者在尝试参数化时可能犯错，例如：错误地在SQL字符串内使用字符串插值（如$"SELECT * FROM Users WHERE Username = '{username}'"），这本质上仍是拼接，无法防止注入。另一个错误是部分参数化，即只对部分输入使用参数，而其他部分仍拼接，这同样危险。此外，使用存储过程时，如果通过拼接构建EXEC语句，也会引入风险。正确做法是全面参数化所有用户输入，包括来自表单、URL、Cookie或API的任何数据。
结合ORM特性增强安全性
虽然Dapper是微ORM，侧重于性能，但你可以结合其他模式提升安全。例如，使用Dapper的QueryMultiple处理多个结果集，避免手动拼接UNION查询。对于动态查询，可以构建安全的SQL构建器类，基于条件添加参数化WHERE子句。同时，始终遵循最小权限原则，数据库连接账户应仅具有必要权限，避免使用SA等高权限账户。在代码审查中，重点检查所有SQL字符串是否包含"+"或"$"拼接，并确保每个变量都有对应的参数占位符（如@param）。
实施代码审查与自动化测试
防止SQL注入需要团队协作和流程保障。在代码审查中，制定检查清单：所有Dapper查询必须使用参数化；禁止出现字符串拼接的SQL；使用静态分析工具（如SonarQube）扫描C#代码，检测潜在注入漏洞。自动化测试方面，编写单元测试模拟恶意输入，验证查询是否安全。例如，测试方法可以传入带有单引号或SQL关键字的输入，确保系统不抛出异常或返回意外结果。集成安全测试工具，如OWASP ZAP，进行定期渗透测试。
总结：安全内联查询的最佳实践
总而言之，在C# Dapper中执行内联查询时，安全取决于是否严格使用参数化。核心实践包括：永远不要拼接用户输入到SQL字符串；始终使用匿名对象或DynamicParameters传递参数；对于动态查询，安全地构建SQL和参数集合；在团队中推行代码审查和自动化安全测试。Dapper本身不自动防止注入，它依赖于开发者的正确使用。通过遵循这些准则，你可以充分利用Dapper的性能优势，同时确保应用程序免受SQL注入威胁，维护数据完整性和系统安全。记住，安全不是可选项，而是开发过程中必须内置的基础部分。
