去年帮一个客户做应急响应，透文攻击者拿shell的透文入口简单得离谱——一个后台的图片上传接口，前端用JS校验了后缀名，透文服务端啥也没管。透文传了个.php上去，透文直接就是透文www-data权限。这事让我觉得有必要把文件上传渗透里那些真正有用的透文东西捋一遍。

前端校验，透文约等于没有

很多开发者的透文安全认知停留在这里：accept="image/*"、JS里判断一下file.name后缀、透文再把上传按钮的透文onclick写个白名单。这种防护打开Burp把请求截下来，透文改个文件名就绕过去了。透文我习惯直接删掉请求里的透文Content-Type，或者把filename改成shell.php,透文前端那套逻辑根本不参与服务端决策。

真正需要看的是服务端怎么处理这个文件。有的框架会把文件先落到临时目录，再根据业务逻辑搬到web目录；有的直接move_uploaded_file。区别很大——前者可能给你留了条件竞争的窗口，后者就是一刀切。

MIME和黑名单，绕起来花样多

服务端如果只查Content-Type,那更省事，Burp里改成image/jpeg就行。稍微认真点的会用黑名单，比如禁止php|jsp|asp。这时候phtml、php5、php7、pht这些别名就派上用场了——前提是目标Apache的AddType或者AddHandler配置里认这些后缀。我在一次测试里碰到过只禁php的，传.phtml直接解析，因为php7.conf里默认把phtml也挂给了PHP模块。

Windows环境更欢乐。shell.php被禁？试试shell.php.或者shell.php空格，IIS和某些版本的PHP会把尾部这些字符吃掉。还有::$DATA这种NTFS数据流写法，配合.php有时候能过黑名单同时被解析。这些不是理论，是实战里真能打通的路子。

白名单才是硬骨头

只允许jpg|png|gif的时候，常规改后缀就失效了。但白名单也不是铁板一块。最经典的是解析漏洞：Apache的AddHandler配了.php，那么shell.php.jpg在某些配置下会从右往左解析到.php为止。Nginx的fastcgi_split_path_info配错，shell.jpg/x.php也能触发。这些漏洞的根子不在上传功能本身，而在web服务器的配置。

另一个方向是文件内容。白名单只查后缀，那就在图片里塞代码。GIF89a文件头后面跟<?php system($_GET['c']); ?>,上传后配合文件包含漏洞用。或者用exif_imagetype这类函数校验的，把恶意代码写进EXIF字段。我试过用copy /b 1.gif + shell.php shell.gif在Windows下拼文件，大部分只查文件头的检测都能过。

.htaccess和.user.ini，另一个维度的打法

如果目标允许上传.htaccess,那基本等于把服务器配置权交出来了。写一行AddType application/x-httpd-php .jpg,所有jpg都当PHP解析。这招在CTF里被玩烂了，但真实环境里我也见过好几次——上传目录权限没收紧，.htaccess可写。

PHP环境还有.user.ini,配合auto_prepend_file可以在所有PHP文件执行前加载指定文件。这个比.htaccess更隐蔽，因为很多运维根本不知道这文件能这么用。

防御这事，得从架构上想

我见过最靠谱的做法是上传目录和web根目录物理分离，文件存到非web路径，通过一个动态脚本读出来。这样就算传了.php,也压根没有URL能访问到。其次是白名单+重命名+内容检测三件套，重命名用随机字符串加白名单后缀，内容检测用getimagesize或者exif_imagetype。再狠一点，上传完直接扔到对象存储，web服务器只负责返回静态资源，连解析的机会都不给。

文件上传这玩意，防御方要堵住所有口子，攻击方只需要找到一个缝。所以别指望一个in_array白名单就完事，得看整个链路——从请求到落盘到解析到访问，每一步都可能出问题。