如何修复.NET Core GET方法字符串参数的SQL注入问题

• 核心根本原因是接口内部的数据库操作逻辑，直接把用户传入的param1等参数拼接进了原生SQL语句，没有做参数化处理。攻击者传入的' AND '1'='1这类SQL片段会被直接当成SQL语法执行，所以被安全工具识别到注入风险。
• 第一个接口使用查询字符串传参，安全扫描工具可以直接在URL的参数值中插入注入测试payload，检测门槛更低。而你第二个未告警的接口使用路由占位符{param1}传参，.NET Core路由默认会对路由参数做基础的特殊字符限制，且部分扫描工具对路由参数的注入测试覆盖率较低，所以暂时没有触发告警，不代表这个接口没有注入风险，如果内部同样有SQL拼接逻辑一样存在漏洞。

• 1. 彻底杜绝SQL拼接，强制使用参数化查询 #

这是修复SQL注入最有效最根本的方案，无论你使用EF Core、Dapper还是原生ADO.NET，都不要直接将用户输入拼入SQL语句。
错误示例：

// 严禁使用的写法：直接拼接用户输入到SQL
string sql = $"SELECT * FROM goods WHERE code = '{param1}' AND area = '{param3}'";

正确写法（原生ADO.NET示例）：

string sql = "SELECT * FROM goods WHERE code = @Param1 AND area = @Param3";
using (var command = new SqlCommand(sql, dbConnection))
{
    // 用参数化方式传值，数据库会自动处理特殊字符转义，不会把输入当成SQL语法执行
    command.Parameters.AddWithValue("@Param1", param1);
    command.Parameters.AddWithValue("@Param3", param3);
    // 后续执行查询逻辑
}

如果使用EF Core，直接用LINQ查询即可，框架默认会做参数化处理，不需要手动拼接SQL。

• 2. 增加输入参数合法性校验 #

对所有用户传入的参数做格式校验，过滤非法字符。比如你案例中的param1看起来是符合特定规则的编号，可以用正则限制允许输入的字符范围，提前拦截非法输入：

using System.ComponentModel.DataAnnotations;

[HttpGet]
[Route("getdata")]
public async Task<string> GetData(
    [RegularExpression(@"^[A-Z0-9.\s]+$", ErrorMessage = "param1格式不合法")] string param1 = "",
    string param2 = "", 
    string param3 = "")
{
    if (!ModelState.IsValid)
    {
        return "参数错误";
    }
    // 业务逻辑
}

• 3. 最小化数据库账号权限 #

给应用程序使用的数据库账号只开放必要的业务权限，不要赋予DROP、ALTER、TRUNCATE等高风险操作权限，就算出现注入漏洞也能最大程度降低损失。

• 4. 全量排查所有接口逻辑 #

对所有未触发告警的接口也要排查内部是否存在SQL拼接逻辑，尤其是用路由传参的接口，避免存在未被扫描工具检测到的隐藏漏洞。

内容的提问来源于stack exchange，提问作者Mr Perfect