造成文件上传漏洞的原因包括

文件上传漏洞的造成根源，从来不是文件那个“上传”按钮本身。它写在开发者对用户输入的上传无条件信任里。

最典型的漏洞例子，是因包某政务网站曾允许上传身份证照片。攻击者把文件名改成“id.jpg.php”，造成服务器端只检查了扩展名是文件否包含“.jpg”，直接放行。上传一个webshell就此落地。漏洞这种低级的因包后缀名黑名单过滤，至今仍活跃在大量中小型系统中。造成黑名单本身就不靠谱——你永远堵不完所有可执行后缀，文件asp、上传aspx、漏洞php5、因包phtml、jspx，甚至奇葩的“.asa”。

比后缀名更隐蔽的坑，是MIME类型校验。很多程序员用浏览器的Content-Type来判断文件类型，觉得“image/jpeg”就一定安全。可这玩意儿是客户端随手就能伪造的。用Burp Suite抓个包，把Content-Type改成image/gif，再塞一段PHP代码进图片尾部，服务器就照单全收了。有个电商平台就这么被打穿过，攻击者上传了带后门的“商品图片”，直接拿到了服务器权限。

还有一类问题出在文件内容检测上。有些系统聪明点，会检查文件头几个字节——比如JPEG的FF D8 FF。但攻击者照样能绕过：在图片末尾追加恶意代码，或者构造一个既合法又含payload的Polyglot文件。我见过一个案例，黑客把PHP代码藏在GIF的注释区里，配合解析器的特性，硬是把图片变成了可执行脚本。你以为你检查了内容，其实只是检查了表面。

服务器配置不当同样致命。明明上传目录不该有执行权限，可有些运维图省事，直接把整个web目录设成755或777。结果上传的.txt文件都能被当成PHP解析。更夸张的是，某些Windows服务器上，IIS6.0的分号截断漏洞——文件名“shell.asp;.jpg”会被解析成ASP脚本执行。这种老古董漏洞，现在偶尔还能在内网系统里碰到。

别忽略文件路径的构造。如果用户能控制上传路径，比如通过参数指定目录，配合../穿越，就能把文件写到任意位置。有家在线文档系统就是这么被攻破的——攻击者把webshell写进了系统的配置文件目录，覆盖了原有的缓存文件。路径拼接时少写一个basename()函数，整条防线就塌了。

最操蛋的是，很多框架已经提供了安全的上传组件，可开发者偏要自己手搓。问就是“框架太重”“需求特殊”。结果呢？过滤逻辑写一半，漏洞留一堆。我审计过某企业内部系统，上传功能用了五个不同的校验函数，互相之间逻辑还冲突——有的允许.php，有的禁止.Php，大小写绕过就这么轻松实现了。

说到底，文件上传漏洞的成因就一句话：你把不可信的数据，当成了可信的文件来对待。文件名要信，路径要信，内容要信，连扩展名都信。可互联网上哪来这么多“可信”？每个上传接口背后，都可能蹲着一个拿着Burp Suite的测试者。他们不按你的规则出牌，只按协议和逻辑的漏洞出招。你在过滤层修修补补，人家换个思路就绕过去了。真正安全的做法是——上传目录禁止脚本执行、文件名服务端随机生成、内容用白名单校验、存储和解析彻底分离。可这些基础操作，至今还是无数网站的奢望。