深入解析C# 6.0 FormattableString：EF Core防SQL注入的核心机制

你是否曾好奇，C#中的 FormattableString 究竟是如何帮助开发者防范令人头疼的SQL注入攻击的？🤔 关键在于理解它与普通字符串拼接的本质区别，以及EF Core如何巧妙地利用其结构特性实现安全的参数化查询。

先搞懂：SQL 注入的根源是什么？

SQL注入的本质在于 恶意输入被直接拼接到SQL语句中，从而篡改了SQL的原始逻辑。看看下面这个危险的例子：

// 恶意用户输入的 orderId："1; DROP TABLE `order`;"
string orderId = "1; DROP TABLE `order`;";
// 直接拼接字符串，最终 SQL 会包含恶意指令
string sql = "SELECT * FROM `order` WHERE Id = " + orderId;
// 执行后会变成：SELECT * FROM `order` WHERE Id = 1; DROP TABLE `order`;

在这种写法里，用户的输入直接“变成”了SQL语句的一部分。数据库会忠实地执行这段被篡改的完整指令，其后果往往是灾难性的，比如数据被清空。

FormattableString 防注入的核心原理

严格来说，FormattableString 本身并不“直接”防注入。它的核心价值在于其结构特性使得EF Core能够实现安全的参数化查询。这背后的核心思想是 「模板与参数分离」，而非简单的字符串替换。

1. FormattableString 的内部结构（关键）

当你使用字符串插值（$"..."）并将其赋值给 FormattableString 类型时，C#编译器不会像处理普通字符串那样立即将插值表达式（如 {orderId}）替换为具体的值。相反，它会将两部分信息分开保存：

• 格式化模板：一个纯字符串，例如 SELECT * FROM order WHERE Id = {0}。这里的 {0} 是一个参数占位符，不是真实的数据。
• 参数数组：一个独立存储的数组，包含了所有插值表达式中计算出的实际值，例如 [1001]。即使是恶意输入，在这里也只是被当作一个普通的字符串值存储。

通过下面这段代码，你可以直观地看到这种分离：

int orderId = 1001;
FormattableString fs = $"SELECT * FROM `order` WHERE Id = {orderId}";

// 格式化模板（仅占位符，无实际值）
Console.WriteLine(fs.Format); // 输出：SELECT * FROM `order` WHERE Id = {0}
// 参数数组（独立存储的实际值）
Console.WriteLine(fs.GetArgument(0)); // 输出：1001

2. EF Core 对 FormattableString 的处理（核心防注入步骤）

当你将一个 FormattableString 对象传递给 FromSqlInterpolated 或 Database.SqlQuery 等方法时，Entity Framework Core 会执行两个关键操作：

• 第一步：将 FormattableString 的「格式化模板」中的C#占位符（{0}, {1}）替换为数据库能够识别的标准参数占位符（例如 @p0, @p1）。
• 第二步：将 FormattableString 的「参数数组」中的值，通过数据库驱动（如 MySqlConnector）以 「参数化查询」 的方式安全地传递给数据库服务器。参数值被“绑定”到占位符上，而不会直接拼接到SQL命令字符串中。

示例：对比“危险拼接”与“安全的 FormattableString”

让我们通过一个具体的SQL注入场景来加深理解。假设用户输入了一个恶意的 orderId：1; DROP TABLEorder`;``。

❶ 危险的字符串拼接（会导致注入）

string maliciousId = "1; DROP TABLE `order`;";
string badSql = $"SELECT * FROM `order` WHERE Id = {maliciousId}"; // 直接拼接成完整字符串
// 最终 SQL：SELECT * FROM `order` WHERE Id = 1; DROP TABLE `order`;
// 执行后会删除 order 表！
_context.Order.FromSqlRaw(badSql).ToList();

❷ 安全的 FormattableString（有效防注入）

string maliciousId = "1; DROP TABLE `order`;";
FormattableString safeFs = $"SELECT * FROM `order` WHERE Id = {maliciousId}";

// EF Core 处理后生成的 SQL（参数化）：
// SELECT * FROM `order` WHERE Id = @p0
// 参数 @p0 的值是："1; DROP TABLE `order`;"（被当作纯字符串值，而非 SQL 指令）
var result = _context.Order.FromSqlInterpolated(safeFs).ToList();

此时，数据库执行的是参数化查询。它会将 @p0 理解为一个“需要查找的Id值”（即查找Id等于字符串 1; DROP TABLEorder; 的记录），而不会将其中的 DROP 解析为SQL指令。因此，注入攻击被成功阻止，查询只会返回空结果（因为通常不存在这样的Id）。

关键注意事项（避免踩坑）

1. FormattableString 本身不防注入，是 EF Core 的处理方式防注入：
   如果你错误地将 FormattableString 转换为普通字符串，再传递给 FromSqlRaw，就会丢失参数化能力，安全屏障瞬间瓦解。

   // 错误用法：转为 string 后失去防注入能力
   string badSql = safeFs.ToString();
   _context.Order.FromSqlRaw(badSql).ToList(); // 依然会执行恶意指令！

2. 必须使用正确的 EF Core 方法接收：

   • 正确：FromSqlInterpolated(FormattableString) 或 Database.SqlQuery<T>(FormattableString)。
   • 错误：FromSqlRaw(string)（即使传入的是由 FormattableString 转换而来的字符串）。

3. 动态表名/列名无法被参数化：
   FormattableString 只能安全地参数化查询中的 「值」 ，无法参数化 「标识符」 （如表名、列名）。例如 $"SELECT * FROM {tableName}"，这里的 {tableName} 会被直接替换，而非参数化。对于此类动态结构，必须手动校验表名/列名的合法性（如使用白名单机制），以防止注入。

总结

1. 核心机制：FormattableString 在结构上分离了「SQL模板（含占位符）」和「参数值」。EF Core 正是利用这一特性，将参数值转换为SQL标准参数（如 @p0）进行传递，从根源上避免了恶意输入篡改SQL逻辑结构。
2. 防注入关键：防注入的功劳不在于 FormattableString 类型本身，而在于EF Core对其进行的「参数化查询」处理。务必使用 FromSqlInterpolated 或 Database.SqlQuery 来接收它。
3. 适用范围：该方案仅适用于参数化查询中的「值」。对于表名、列名等数据库对象标识符，需要额外的安全校验措施。

在云栈社区的C#和数据库安全板块，你可以找到更多关于如何编写安全、高效数据库访问代码的深度讨论和实践案例。