ASP.NET Core Web API Fortify扫描问题修复咨询

1. Mass Assignment：Insecure Binder Configuration（高优先级） #

Fortify检出该问题的核心原因是：ASP.NET Core默认会自动绑定模型的所有公开属性，存在潜在批量赋值风险——若后续扩展CreateRequestModel新增属性，攻击者可能构造额外请求参数，对未预期的属性进行赋值。以下是针对性修复方案：

方案一：用[Bind]特性显式指定允许绑定的属性 #

直接在Action参数或模型类上标记允许绑定的字段，严格限定输入范围：

// 在Action参数上添加Bind特性
[HttpPost]
public async Task<IActionResult> Create([Bind(nameof(CreateRequestModel.Name), nameof(CreateRequestModel.User))] CreateRequestModel model)
{
    bool status = await _service.Create(model);
    return Ok(status);
}

或在模型类上全局配置：

[Bind(nameof(Name), nameof(User))]
public class CreateRequestModel
{
    public string Name { get; set; } = default!;
    public string User { get; set; } = default!;
}

方案二：输入DTO与业务模型分离 #

创建仅包含前端需传递字段的输入DTO，再手动或通过映射工具转换为业务模型，从根源隔离输入与业务逻辑：

// 输入专用DTO
public class CreateRequestDto
{
    public string Name { get; set; } = default!;
    public string User { get; set; } = default!;
}

// Action中使用DTO
[HttpPost]
public async Task<IActionResult> Create(CreateRequestDto dto)
{
    // 手动映射到业务模型（也可使用AutoMapper等工具）
    var model = new CreateRequestModel
    {
        Name = dto.Name,
        User = dto.User
    };
    bool status = await _service.Create(model);
    return Ok(status);
}

2. ASP.NET MVC Bad Practices：Controller Action Without AntiForgery Validation（低优先级） #

该问题是Fortify基于MVC场景的默认检查，但纯Web API场景下，传统Cookie-based防伪造验证通常不适用（多为服务间调用或使用JWT/API Key认证）。修复方案如下：

方案一：禁用单个Action或全局的防伪造验证 #

若API仅面向非浏览器客户端（如后端服务、移动端），可直接禁用验证：

// 单个Action禁用
[HttpPost]
[IgnoreAntiforgeryToken]
public async Task<IActionResult> Create(CreateRequestModel model)
{
    bool status = await _service.Create(model);
    return Ok(status);
}

若所有API都不需要防伪造验证，可全局配置：

// .NET 6+ Program.cs
builder.Services.AddControllers(options =>
{
    options.Filters.Add(new IgnoreAntiforgeryTokenAttribute());
});

方案二：标记为Fortify误报 #

若API已通过JWT、API Key等方式完成身份认证，且确认无浏览器客户端调用，可在Fortify扫描结果中将该问题标记为误报——传统防伪造逻辑不适用于纯服务间的API场景。

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