黑名单这套东西，出发点没错——把已知的危险后缀列出来，见到就拒。可你只要在网上稍微翻一翻绕过手法，就会发现它几乎挡不住稍微用点心的人。上传文件漏洞里最常见的一类，就是过滤器只盯着扩展名，而文件真正的行为由服务器怎么解析决定。这两件事没对上，规则列得再长也是白列。
上传文件漏洞的黑名单天生防不住什么
黑名单的逻辑是「我列出坏的，剩下的都放过」，这等于从一个无限大的集合里取补集。攻击者不用会所有的，只要找到一个你没列的就行。.php 被拦了，.php3、.php5、.phtml、.pht 挨个试一遍；大小写混着来，PhP；后缀叠着来，shell.php.jpg，有的代码只查最后一段，服务器却按前面的来解析。还有更省事的：.htaccess 和 web.config 这种配置文件本身，传上去就能改解析规则。这些东西在很多老名单里压根没出现，因为写名单的人满脑子只有脚本后缀。
上传文件漏洞真正的分界线在文件落地之后
判断一个上传功能安不安全，别只看它拦了什么，要看落地的目录允许什么。文件存到 web 根目录下面、目录又允许执行，那你前面拦得再严，只要漏一个就是后门。反过来，文件存在 web 根目录之外，或者丢进对象存储、只由后端读出来再转发，那即使传了个 php 上去，它也不会被当成程序跑起来。目录权限、解析配置、存储位置，这三样比后缀名单管用得多。
白名单不是万能钥匙，但比黑名单靠谱
白名单是「只允许我认识的」，思路反过来，安全性天然好一截。坑在于很多人把白名单当成「后缀对了就没事」。图片站允许 jpg、png，那传一张真的图片、里面塞一段脚本，配合某些解析漏洞或者文件包含，照样能出事。所以白名单得配两件事：一是重编码，图片进来用 GD 或者 ImageMagick 重新生成一遍，元数据里夹的东西基本就废了；二是改名，别用用户给的文件名，用随机串加业务后缀。原来那个名字里带 ../ 或者一堆特殊字符的，很多麻烦就是从这儿溜进来的。
还有个常被忽略的点，判断类型靠 Content-Type。那个是浏览器给的，随手就能改，服务端该做的是读文件头，也就是 magic bytes，再结合 getimagesize 这类函数确认它真是图片。两步都不难，难的是有人图省事只做了一步，还觉得自己已经挡住了。
那些看着不像脚本的文件
svg 是图片，但它是 XML，里面能写脚本；pdf 能带 js；zip 解压出来是什么谁也不知道；甚至一个 .html 传上去，就能拿来钓鱼或者做跳转。黑名单很少列这些，因为它们「看起来无害」。所以重点不是把名单补到多长，是先问清楚这个上传口到底要收什么——收图片就只收图片，收简历就只收 pdf 和 doc，多余的一律不进。业务范围收窄了，攻击面自己就小了。
漏洞被利用之后，痕迹都留在哪
多数情况是 webshell 落在 uploads、attachment、cache 这类目录里，文件名奇奇怪怪，体积不大，访问时间还挺集中。你要是从来没打开看过这些目录，那基本等于门没锁。做法很土但有效：上传目录单独放，权限只给读不给执行；定时扫一遍目录里新增的可执行文件；把 web 访问日志里对这些路径的 POST 和 GET 挑出来单独看。别指望杀毒软件替你兜底，特征库对一句话木马经常没反应。
虚拟主机和共享空间上，能做的有限但关键
用虚拟主机的人常问，控制面板里没那么多选项，是不是就没法管了。倒也不是。附件目录别和程序目录混在一起，能设权限就设成只读；面板里关掉用不上的解析类型；上传入口必须登录才能用，别留一个匿名上传的页面。这些动作不复杂，但能挡掉一大批脚本小子的批量扫描，真正盯着你来的那种，本来也不是靠这几步能挡住的。
还有个容易偷懒的地方：上传之后直接给一个公开的 URL。更稳的做法是先落临时目录，校验、重命名、重编码都做完，再挪到正式位置，公开访问走一层后端转发。多这一步，很多「传上去了但还没被处理」的空档就没了。
顺序上我一般这么看：先看存储位置和目录权限，再看解析配置，然后是后缀过滤，白名单配上重命名和重编码，最后才是日志和目录的定期检查。顺序反了，容易在名单上耗掉一堆时间，真正的问题还在原地站着。名单可以留，但当它是第一道门，别当它是墙。
【版权声明】：本站内容若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
