仅校验后缀名不可靠，因用户可随意修改（如hacked.exe→report.pdf）；必须结合服务端Magic Number校验与ContentType双因子验证，并防范空MIME、路径遍历等绕过。
只校验后缀名为什么不可靠
用户可以轻易修改文件扩展名，比如把 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 校验只是体验优化，删掉照样能发请求。
