扫描发现Reflection Injection漏洞，求Telerik Grid场景下的修复方案

核心问题本质 #

你遇到的这个漏洞，是因为直接把用户可控的filter参数（对应Grid列名）传入了反射相关逻辑里。攻击者可以篡改这个参数，尝试调用非预期的字段/方法，绕过正常业务逻辑甚至搞破坏。

1. 强制白名单验证，堵死非法输入 #

提前把那20个合法列名做成硬编码的白名单，控制器接收到filter参数后，先检查参数是否在白名单里，不在就直接拒绝：

// 预定义合法列名的白名单
private readonly HashSet<string> ValidFilterColumns = new HashSet<string>
{
    "UserName", "Email", "CreateTime", // 替换成你的20个列名
};

public IActionResult LoadGridData(string filter)
{
    if (!ValidFilterColumns.Contains(filter))
    {
        return BadRequest("非法筛选参数");
    }
    // 继续后续正常逻辑
}

注意：白名单必须是硬编码或从可信配置读取，绝对不能从用户输入或不可信来源动态生成。

2. 把反射调用和用户参数彻底解耦 #

如果之前是直接用filter参数做反射（比如typeof(UserModel).GetProperty(filter)），必须改成用白名单映射好的属性信息，彻底避免用户参数直接接触反射逻辑：

// 提前映射合法列到对应的属性信息
private readonly Dictionary<string, PropertyInfo> ColumnPropertyMap = new Dictionary<string, PropertyInfo>
{
    {"UserName", typeof(UserModel).GetProperty("UserName")},
    {"Email", typeof(UserModel).GetProperty("Email")},
    // 依次添加所有合法列
};

public IActionResult LoadGridData(string filter)
{
    if (!ColumnPropertyMap.TryGetValue(filter, out var targetProperty))
    {
        return BadRequest("非法筛选参数");
    }
    // 直接用targetProperty做后续操作，不再碰用户输入的filter
}

3. 限制Telerik Grid的前端请求范围 #

在Razor视图的Grid配置里，明确只允许对合法列做筛选，同时限制筛选操作符，减少前端层面的风险（但不能替代后端验证，攻击者能绕前端）：

@(Html.Kendo().Grid<UserModel>()
    .Name("UserGrid")
    .Columns(columns =>
    {
        columns.Bound(c => c.UserName);
        columns.Bound(c => c.Email);
        // 只配置那20个合法列
    })
    .DataSource(dataSource => dataSource
        .Ajax()
        .Read(read => read.Action("LoadGridData", "User"))
        .Filterable(filterable => filterable
            .Extra(false) // 限制只能单字段筛选
            .Operators(operators => operators
                .ForString(str => str.Clear()
                    .Contains("包含")
                    .EqualTo("等于"))) // 只允许必要的筛选操作
        )
    )
)

4. 开启ASP.NET Core的严格参数绑定 #

在项目配置里启用严格绑定模式，避免意外绑定到非预期的属性，进一步加固参数校验：

// Program.cs中配置
builder.Services.AddMvc(options =>
{
    // 启用严格绑定，忽略未定义的请求参数
    options.ModelBindingExceptionsAllowed = false;
    options.AllowValidatingTopLevelNodes = true;
});

5. 修复后务必验证 #

• 用Seeker重新扫描，确认漏洞已修复。
• 手动构造恶意请求，比如传入白名单外的字段名，确认后端返回错误。
• 定期排查项目里所有用反射的地方，避免再出现类似问题。

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