ASP.NET Core中能否信任IFormFile的.Length属性？

嘿，这个问题问到点子上了——涉及API安全的话，任何用户可控的输入都不能掉以轻心！直接给你结论：IFormFile.Length完全不可信，它本质上就是请求头里Content-Length字段的映射，属于用户可篡改的输入。

为什么不可信？ #

当用户上传文件时，客户端（浏览器、Postman或者恶意脚本）会在请求中携带Content-Length头，告诉服务器“我要传的文件这么大”。ASP.NET Core会把这个值直接赋值给IFormFile.Length属性。但恶意用户可以轻松篡改这个头：比如实际要传100MB的文件，却把Content-Length改成1KB，这样如果你的验证逻辑只检查Length，就会直接绕过大小限制，让超大文件溜进服务器，导致存储耗尽或者DoS攻击。

正确的文件大小验证姿势 #

既然不能信Length，那该怎么防滥用？给你几个靠谱的方案：

1. 全局配置请求大小限制
   在Program.cs/Startup.cs里配置FormOptions，直接限制 multipart 表单的最大总大小：

   builder.Services.Configure<FormOptions>(options =>
   {
       // 限制为10MB，根据你的需求调整
       options.MultipartBodyLengthLimit = 10 * 1024 * 1024;
   });
   

   超过这个大小的请求，服务器会直接拒绝，根本不会进入你的API逻辑。

2. 针对单个端点做细粒度限制
   如果不同端点的限制不一样，可以用RequestSizeLimit特性标记控制器方法：

   [HttpPost("upload")]
   [RequestSizeLimit(5 * 1024 * 1024)] // 这个端点限制5MB
   public async Task<IActionResult> Upload(IFormFileCollection files)
   {
       // 处理逻辑
   }
   

3. 读取文件流时主动限制
   即使有了上面的限制，在读取文件内容的时候也要留个心眼——比如用Stream.CopyToAsync时，不要无限制读取，或者自己控制读取的字节数：

   var maxAllowedBytes = 10 * 1024 * 1024;
   var bytesRead = 0;
   var buffer = new byte[8192];
   
   using (var stream = new FileStream("path/to/save", FileMode.Create))
   {
       int read;
       while ((read = await file.OpenReadStream().ReadAsync(buffer)) > 0)
       {
           bytesRead += read;
           if (bytesRead > maxAllowedBytes)
           {
               // 超过限制，抛出异常或者返回错误
               throw new InvalidOperationException("文件大小超过限制");
           }
           await stream.WriteAsync(buffer, 0, read);
       }
   }
   

额外提醒 #

就算客户端发送了正确的Content-Length，也可能存在传输过程中数据截断的情况，所以实际读取完成后，可以对比bytesRead和file.Length，如果不一致，说明文件不完整，应该拒绝处理。

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