只校验后缀名为什么不可靠
用户可以轻易修改文件扩展名，比如把
hacked.exe改成
report.pdf，后缀检查就完全失效。仅依赖
Path.GetExtension(file.FileName)判断类型，在安全要求稍高的场景（如用户头像、文档上传）属于明显漏洞。
实操建议：
后缀名检查只能作为第一道快速过滤，必须配合更可靠的验证手段 不要用string.EndsWith(".pdf") 这类松散匹配——忽略大小写、不处理多点名（file.tar.gz）、不防空格和编码绕过 推荐用
Path.GetExtension(fileName).ToLowerInvariant()统一处理后再比对白名单
服务端读取文件头（Magic Number）才是关键
MIME 类型由客户端通过
Content-Type字段提供，但该字段可被任意篡改。真正可信的是文件开头的字节签名（即 Magic Number）。C# 中需打开文件流，读取前若干字节比对已知签名。
实操建议：
不要信任IFormFile.ContentType，尤其在
multipart/form-data上传中它只是浏览器传来的字符串 对小文件（如图片、PDF），读取前 4–8 字节足够识别：PNG 是
89 50 4E 47，JPEG 是
FF D8 FF，PDF 是
25 50 44 46使用
await file.OpenReadStream().ReadAsync(buffer, 0, buffer.Length)，注意捕获
IOException和流提前结束情况 避免全文件加载进内存；对大文件可设上限（如只读前 1024 字节）并跳过校验（或改用分块读取）
结合 IFormFile.ContentType 和 Magic Number 的安全校验流程
理想做法是「双因子验证」：既检查客户端声称的 MIME（用于快速拦截明显错误），又校验实际字节签名（用于兜底防伪造）。二者都通过才放行。
实操建议：
定义白名单字典，例如：new Dictionary<string byte> { ["image/jpeg"] = new byte[]{ 0xFF, 0xD8, 0xFF } }</string>
先检查 file.ContentType是否在白名单键中；不在则直接拒绝 再读取文件头，确认是否匹配该 MIME 对应的签名；不匹配则拒绝（说明是伪造的 MIME + 真实恶意内容） 特别注意：某些格式（如 Office 文档）有多个合法签名，需查 RFC 或真实样本归纳，不能只记一个
常见陷阱与绕过方式
很多开发者以为加了后缀+MIME 检查就安全了，其实攻击者早有一套成熟绕过链。
容易踩的坑：
ContentType为空时不做处理——攻击者可构造空 ContentType 绕过 MIME 检查，此时必须 fallback 到 Magic Number 校验 未限制文件名长度或路径遍历字符（
../、
%2e%2e%2f），导致写入任意目录 用
file.FileName直接拼接保存路径——未清理
..\、
:$DATA（NTFS ADS）等危险序列 PDF/Office 文件内嵌可执行对象（如 JS、OLE）——这已超出上传校验范畴，需后续沙箱扫描
最常被忽略的一点：校验逻辑必须在服务端完成，且所有输入（文件名、Content-Type、文件流）都要视为不可信。前端 JS 校验只是体验优化，删掉照样能发请求。
