HttpPostedFileBase属性是否可伪造？ContentLength等需自行校验吗？

关于ContentLength的可信度与验证建议 #

不要完全信任HttpPostedFile.ContentLength属性。这个值直接取自HTTP请求头中的Content-Length字段，而请求头是可以被客户端随意伪造的。

比如攻击者可以构造请求，把ContentLength设为100字节，但实际上传的文件内容却有10MB。如果代码仅依赖这个属性做长度校验，可能出现内存分配不足、存储逻辑异常，甚至被绕过大小限制上传恶意文件。

最佳实践：必须自行读取文件流计算实际长度来验证。小文件可直接读取整个流到内存后获取长度；大文件建议分段读取流并计数，或者写入临时存储后检查实际文件大小，再和设定的长度阈值对比。

关于ContentType与Magic Numbers校验的必要性 #

HttpPostedFile.ContentType同样不可信——它来自请求头的Content-Type字段，客户端可以轻松篡改。比如把恶意可执行文件的Content-Type改为image/jpeg，这个属性就会显示为图片类型，但文件本质还是危险的可执行程序，直接依赖这个属性会导致文件类型校验完全失效。

而检查文件的**Magic Numbers（文件头签名）**是行业通用的安全校验手段，因为它基于文件实际内容校验，不受请求头伪造影响。比如：

• JPEG文件开头字节是FF D8 FF
• PNG文件开头是89 50 4E 47
• EXE文件开头是4D 5A

通过读取文件前几个字节匹配这些签名，就能准确判断文件真实类型，有效阻挡恶意文件伪装。

纵深防御的补充 #

你提到的Web.config中httpRuntime的maxRequestLength是服务器层面的请求大小限制，属于第一道防线，但不能仅依赖它。内部代码中的长度、类型校验是第二道关键防线，两者结合才能构建完整安全防护——即使外部配置被意外修改，内部校验依然能拦截恶意请求。

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