DVWA文件上传漏洞四等级实战：MIME校验、白名单与重编码防御

DVWA里的File Upload模块，我前后带着不同基础的人练过好几轮，每次都会遇到同一个现象：有人三分钟就把Low难度打通了，然后觉得"文件上传漏洞不过如此"；等到切到Medium、High，抓包改了半天还是传不上去，卡在那里开始怀疑人生。这个模块真正的价值从来不是"传上去一个文件"这个动作本身，而是让你完整看到一条防线是怎么一层层搭起来、又怎么一层层被找出缝隙的。我打算把四个难度等级按源码逻辑拆开，把每一步为什么这么做、参数为什么这么设讲清楚，顺带把我在实操中踩过的坑和排查顺序整理出来。适合刚接触Web安全靶场的新手跟着做一遍，也适合已经会"传文件"但说不清防御原理的朋友回头补课。全文所有操作都限定在本地搭建的授权靶场环境内，目的只有一个——把防御写对。

1. File Upload模块在练什么：先看懂靶场的设计意图

1.1 一次"上传头像"背后藏着三段信任

很多人对文件上传漏洞的理解停留在"传个脚本上去就能执行"，这个认知太窄了。真实业务里上传接口无处不在：头像、附件、导入的表格、富文本里的插图、发票扫描件。每一次上传，服务端都不得不做出三段判断，而这三段判断任何一段松了，问题就来了。

第一段是身份与权限的信任：这个请求是不是登录用户发的，他有没有权限往这个位置写东西。第二段是内容的信任：这个文件真的是它自称的那种类型吗，名字里那个扩展名可信吗，大小在合理区间吗。第三段是存储位置与执行环境的信任：文件落到哪个目录，那个目录下的文件会不会被当作可执行内容来处理。

DVWA这个模块专门练的是第二段和第三段。它在四个等级里逐步收紧"内容信任"的判定条件，同时把一个关键前提留给你自己发现：上传目录位于Web可访问路径下。这个前提不是靶场偷懒，而是现实中大量出问题的根源——开发者只想着"把文件存起来"，没想过"存的地方正好能被浏览器当代码解析"。

我在讲这个模块之前一定会先问一句：你觉得上传漏洞的根因是代码写错了，还是部署姿势错了？大部分人会答代码。但如果上传目录本身禁止解析、文件被强制重命名成无扩展名、存储走的是独立的对象存储域名，那么即使校验代码写得稀烂，攻击面也被砍掉一大半。这个视角很重要，它决定了你后面看Impossible等级源码时，能看出哪些是代码层的修补、哪些是架构层的兜底。

1.2 四个难度等级是一条递进的防线

DVWA的难度设计逻辑很清晰，它的目的不是让你"打穿"，而是让你体会防御者在每个阶段加了什么、这个加法为什么不够。我把四个等级的判定条件整理成一张表，后面每一章都会对着这张表展开。

看这张表你能发现一个很有意思的现象：Medium加了MIME校验却把扩展名校验丢了，High加了扩展名白名单和图像校验却把MIME校验丢了。这不是靶场写错了，而是刻意模拟真实开发中那种"补一个洞、漏一个洞"的典型状态。防御是一个整体，任何一个单点检查都不构成防线。

所以练这个模块的正确姿势不是"记绕过手法"，而是每上一个等级先问自己三个问题：这一级新增了什么检查？这个检查依赖的输入值，客户端能不能控制？如果控制不了，还有没有别的路径达到同样目的？把这三问养成习惯，比背十种绕过技巧有用得多。

1.3 实验环境与边界：只在本地靶场里折腾

环境这块我不展开长篇大论，只讲几个决定成败的点。靶场建议用容器方式跑在本地，映射端口到本机，浏览器访问本机地址即可，整个实验过程中不接触任何外部网络目标。这套组合的好处是环境可随时销毁重建，改坏了删掉容器重来，不会污染本机。

浏览器侧务必装一个能拦截并修改请求的代理工具，并且把浏览器的代理指向它、装好对应的根证书。这一步是后面所有等级实操的基础，尤其是Medium和High，不抓包你根本看不出服务端在检查什么。代理工具的过滤规则里把本地靶场域名加进去，避免无关流量干扰视线。

还有两个细节容易忽略。一是上传目录的可写权限，容器化部署一般没问题，如果你是手工在虚拟机里装的环境，记得确认上传目录的属主与Web进程用户一致。二是实验记录习惯，我建议每完成一级就存一份请求响应记录，包括原始请求头、响应体里的返回路径、以及访问结果的截图。这些记录在你回头复盘或者给别人讲的时候，价值远超你当时的记忆。

注意：整个实验只在你自己的本地靶场里进行。任何针对非授权目标的类似操作都不属于学习范畴，本文所有内容均以理解防御原理为目的。

2. Low等级：黑名单思路的三个致命假设

2.1 源码拆解：只有一次move_uploaded_file

Low等级的源码短到有点好笑，核心就三步：拼路径、搬文件、打印结果。它没有做任何类型判断，没有大小限制，也没有对文件名做清洗。basename()取的是文件名部分，防止路径穿越，这个函数本身用得没错，但它只处理了"名字里带目录分隔符"这一种情况。

<?php if( isset( $_POST[ 'Upload' ] ) ) { // 拼接目标路径，注意这里直接用上传文件的原始文件名 $target_path = DVWA_WEB_PAGE_TO_ROOT . "hackable/uploads/"; $target_path .= basename( $_FILES[ 'uploaded' ][ 'name' ] ); if( !move_uploaded_file( $_FILES[ 'uploaded' ][ 'tmp_name' ], $target_path ) ) { echo '<pre>Your image was not uploaded.</pre>'; } else { echo "<pre>{$target_path} succesfully uploaded!</pre>"; } } ?>

这段代码里藏着三个假设，而且每一个都站不住脚。假设一：用户传上来的文件就是他想传的那种文件——完全没有验证，用户说是图片那就是图片。假设二：文件名是安全的——只用了basename()，没有过滤扩展名，也没有重命名。假设三：上传目录是安全的——文件落在Web可访问目录，扩展名保留，服务端配置允许该扩展名被解析。

这三个假设同时成立的后果就是：你上传什么，服务器就把它当什么处理。这也是为什么这个漏洞在真实项目里一旦出现，往往直接通向最严重的结果。

2.2 实操：上传一个能被解析的最小验证文件

验证思路很简单，不需要复杂的载荷，一段能打印出固定字符串的最短代码就够用了。我习惯用最朴素的形式，写成upload-ok.php这类文件，内容就是输出一行标记文本。上传之后访问返回的路径，如果页面上出现那行标记，就说明文件被当作服务端代码执行了。

具体步骤：打开Low等级页面，选择刚才那个文件，点上传，页面会回显一个完整路径，类似.../hackable/uploads/upload-ok.php。复制这个路径到浏览器新标签页打开。如果显示的是那行标记文本，实验完成；如果显示的是文件源码原文，说明文件被当作文本返回了，这时候要去看服务端配置。

这里有个新手极容易卡住的点：上传成功不等于执行成功。回显里明确写着"succesfully uploaded"，很多人到这一步就以为打完了。实际上上传只是把文件放到了磁盘上，能不能执行取决于两件事——目录是否在Web根下、该扩展名是否被交给脚本解析器处理。这两件事任何一件不成立，你看到的就只是一段被原样输出的文本。我在带人练的时候会特意让他们先看到"源码被原样显示"的状态，再去看配置，这样对整条链路的理解会扎实很多。

2.3 黑名单为什么天生防不住

Low等级没有校验，但很多人第一次尝试自己写防护时会选择黑名单：列一堆危险扩展名，命中就拒绝。这个思路我见过太多人用，也见过太多人被它坑。原因不复杂——黑名单是穷举，而扩展名的可能性不是有限集。

服务端能解析的扩展名远不止常见的那几个，不同的中间件、不同的版本、不同的配置都可能额外支持一些别名形式；大小写变形、末尾点号、多余空格、双扩展名，这些在特定解析规则下都可能生效；再加上配置文件本身的解析范围，比如某些配置下把某个后缀映射到脚本处理器，这个映射关系在运维手里，开发写代码时根本不知道。

所以我在任何场合都坚持一个观点：文件上传的校验必须是白名单。只允许明确列出的少数类型通过，其余一律拒绝。白名单的失效场景收敛得多，主要就剩"白名单里的类型被当作可执行内容"这一类，而这一类可以通过存储位置和解析配置彻底封死。这个结论你在看完High和Impossible两级之后会更认同。

实操心得：Low等级最容易被当成"送分题"草草带过。我的建议是反过来，在这一级多花十分钟，把上传目录的位置、Web根目录的边界、服务端的解析配置都摸清楚。后面三级的所有绕过，本质上都是在跟这三件事打交道。

3. Medium等级：类型校验引入后怎么观察和突破

3.1 源码变化：MIME检查与大小上限

切到Medium，源码多了一层判断，检查的是$_FILES['uploaded']['type']，同时加了100KB的大小上限。看起来"加了校验"，实际上加的这个校验有一个根本性缺陷：它读的是请求里客户端自己声明的内容类型，而不是文件真实内容。

<?php if( isset( $_POST[ 'Upload' ] ) ) { $target_path = DVWA_WEB_PAGE_TO_ROOT . "hackable/uploads/"; $target_path .= basename( $_FILES[ 'uploaded' ][ 'name' ] ); // 只校验客户端声明的类型和大小 $uploaded_type = $_FILES[ 'uploaded' ][ 'type' ]; $uploaded_size = $_FILES[ 'uploaded' ][ 'size' ]; if( ( $uploaded_type == "image/jpeg" || $uploaded_type == "image/png" ) && ( $uploaded_size < 100000 ) ) { if( !move_uploaded_file( $_FILES[ 'uploaded' ][ 'tmp_name' ], $target_path ) ) { echo '<pre>Your image was not uploaded.</pre>'; } else { echo "<pre>{$target_path} succesfully uploaded!</pre>"; } } else { echo '<pre>Your image was not uploaded. We can only accept JPEG or PNG images.</pre>'; } } ?>

关键点在于$_FILES['uploaded']['type']这个值的来源。它来自HTTP请求体里 multipart 分段头部的Content-Type字段，这个字段是浏览器根据文件扩展名猜出来的，而请求是客户端构造的，所以这个值客户端想写什么就写什么。服务端拿一个完全由客户端控制的字符串做安全判断，等于把门锁的钥匙挂在门上。

更值得注意的是，这一级没有扩展名校验。也就是说即便你把类型声明改成图片，文件名的扩展名依然原样保留。这两个漏洞叠加，构成了Medium的全部突破口。

3.2 抓包改Content-Type的完整操作

操作路径是这样：先准备一个和前面一样的最小验证文件，扩展名保持不变。打开代理工具的请求拦截，在页面上选择文件点上传，请求被拦下来之后，找到请求体里对应这个文件的那一段，把它的Content-Type值改掉。

请求体长这样，你需要动的是第二个Content-Type：

------WebKitFormBoundaryXxxx Content-Disposition: form-data; name="uploaded"; filename="upload-ok.php" Content-Type: application/x-php <文件内容> ------WebKitFormBoundaryXxxx Content-Disposition: form-data; name="Upload" Upload ------WebKitFormBoundaryXxxx--

把文件分段头里的Content-Type: application/x-php改成Content-Type: image/png，放行请求。服务端读到$uploaded_type是image/png，判断通过，文件按原名落到上传目录，扩展名.php保留。后续访问路径验证执行的步骤和Low等级完全一样。

这里必须提醒一个高频翻车点：有些代理工具会显示两个 Content-Type，一个是请求头部的，一个是分段内部的，只改请求头部的没用。请求头部那个描述的是整个 multipart 请求体，服务端代码读的是分段内部那个。改错位置的现象是"依然提示只能接受JPEG或PNG"，很多人到这一步以为是工具问题，其实是改错了行。我第一次带人做的时候就遇到这个，来回折腾了二十分钟。

另一个细节是大小。100KB 这个上限对应的是文件字节数，你随手写的那几行验证代码远小于这个值，不成问题。但如果你后面做High等级的图片马实验，就要认真控制文件体积了，我在下一章会讲具体怎么压。

3.3 常见MIME对照与容易踩的坑

不同文件类型在浏览器里被推断出来的 MIME 值不一样，做实验时你可能需要按需构造。下面这张表是我平时备查用的，覆盖了靶场里最常遇到的几种：

有几个坑值得单独说。第一，MIME 值不带参数。有时候你会看到image/jpeg; charset=binary这种带参数的形式，靶场里做的是全等比较，带参数会判不等，直接失败。第二，大小写敏感。image/JPEG和image/jpeg在字符串全等比较下是两回事。第三，不要指望浏览器自动帮你改。浏览器是根据你选中的文件的扩展名推断的，你想让一个.php文件声明成image/png，只能手工改请求，没有任何前端操作能做到。

还有一点经验：做这类实验时，最好把代理工具的拦截规则配置成"只拦目标域名下的上传请求"。否则你在页面上点个按钮，一堆静态资源的请求全被拦下来，找目标请求要花很久。这个优化看着小，实际能省掉大量时间。

注意：改包之后如果上传成功但访问路径报404，先别怀疑绕过失败，去核对回显的路径有没有被截断、目录名有没有拼错。我遇到过的"绕过失败"里，至少三成是路径复制少了一段。

4. High等级：白名单、重命名、图像校验的三重门

4.1 getimagesize在检查什么

High等级的变化幅度大得多，一次性上了三道检查：扩展名白名单、大小上限、以及getimagesize()校验。同时它做了一件对攻击者很不友好但非常正确的事——重命名。

<?php if( isset( $_POST[ 'Upload' ] ) ) { $target_path = DVWA_WEB_PAGE_TO_ROOT . "hackable/uploads/"; $target_path .= basename( $_FILES[ 'uploaded' ][ 'name' ] ); $uploaded_name = $_FILES[ 'uploaded' ][ 'name' ]; $uploaded_ext = substr( $uploaded_name, strrpos( $uploaded_name, '.' ) + 1 ); $uploaded_size = $_FILES[ 'uploaded' ][ 'size' ]; $uploaded_tmp = $_FILES[ 'uploaded' ][ 'tmp_name' ]; if( ( strtolower( $uploaded_ext ) == "jpg" || strtolower( $uploaded_ext ) == "jpeg" || strtolower( $uploaded_ext ) == "png" ) && ( $uploaded_size < 100000 ) && getimagesize( $uploaded_tmp ) ) { // 重命名为随机字符串，扩展名沿用校验通过的那个 $target_path .= md5( uniqid() . $uploaded_name ) . '.' . $uploaded_ext; if( !move_uploaded_file( $uploaded_tmp, $target_path ) ) { echo '<pre>Your image was not uploaded.</pre>'; } else { echo "<pre>{$target_path} succesfully uploaded!</pre>"; } } else { echo '<pre>Your image was not uploaded. We can only accept JPEG or PNG images.</pre>'; } } ?>

getimagesize()是 PHP 的图像信息函数，它读文件头部的字节，判断这是不是一张合法图像，并返回宽高、类型等信息。判断失败返回 false，条件不成立，上传被拒。这个函数只看文件头，不看整体结构，也不看文件里除了图像数据之外还有什么——这就是它的边界所在，也是这一级留给你思考的地方。

重命名这一步的影响非常大。文件名变成一串哈希加固定扩展名，意味着你无法通过猜测或控制文件名来让文件落到特定路径、也无法让扩展名变成可执行类型。扩展名白名单 + 重命名这两条组合起来，基本堵死了"直接上传可执行文件"这条路。

4.2 图片马的构造与验证路径

既然扩展名被锁死、名字被重写，思路就只能转向"让一个合法图片文件里额外携带内容"。做法是把代码片段追加到一张真实图片文件的末尾。图片解析器读到图片数据结束就停了，后面的字节它不关心；而如果这个文件被别的机制当作代码解析，那些追加的字节就有机会被执行。

构造过程很简单：找一张体积小的图片，用命令行把一段文本追加进去。命令形式如下，>>是追加，不会破坏原有字节：

# 先确认原图大小，控制在100KB以内，留出追加空间 ls -l base.jpg # 把代码片段追加到图片末尾 printf '%s' '<?php echo "img-ok"; ?>' >> base.jpg # 再次确认体积，确保没超上限 ls -l base.jpg

体积控制这一块要算一下。假设原图是 60KB，追加的内容不到 30 字节，总计 60KB 出头，离 100KB 上限还有很大余量，安全。如果你手上只有 95KB 的图，那就悬了，建议先压一下图片尺寸。我一般会用图像处理工具把图压到 20KB 以内，这样后面无论追加什么内容都不会顶到上限。

上传这个文件，扩展名.jpg通过白名单，getimagesize()读到合法图片头也通过，文件被重命名后落到上传目录。到这一步，上传环节是完全成功的，但你去访问那个路径，看到的是一张图片，追加的代码不会执行。

这就是High等级真正想让你意识到的事：上传成功和代码执行之间，还隔着一层"解析"。单靠上传这一个点，你已经到极限了。要继续往下走，必须借力别的环节。

4.3 单靠上传已经不够：二次利用的链条

靶场里有个配套的思路可以做，就是把上传和文件包含结合起来。如果你所在的靶场版本同时开放了文件包含模块，你可以构造一个请求，让包含函数去读取你上传的那个图片文件——只要包含逻辑对文件路径的限制足够宽松，图片里追加的那段代码就有可能被解释执行。

这个组合练习的价值不在于"又打通了一关"，而在于让你看清攻击链的构成：单点防御做到位之后，风险并没有归零，只是被推迟到了下一个环节。真实项目里这条链可能更长——上传的图片被某个图片处理服务读取、处理服务的输出路径可控、输出文件又落在可访问目录，每一环单独看都不算漏洞，连起来就是一条完整的路径。

这也是我在做代码审计时的一个固定动作：看到一个上传点，不只看上传代码本身，还要追这个文件后面会被谁读、被谁处理、处理结果落到哪。这个追踪习惯帮我找出过好几个"单看每一处都没问题"的组合风险。

顺带说一句，getimagesize()的校验也不是铁板一块。它对文件头的依赖意味着，某些精心构造的文件头可以让它通过校验，而文件的实际内容结构并不完整。这类问题的根源在于"用轻量校验代替完整解析"。我在生产环境里给的建议一直是：不要用getimagesize()当作安全校验的主力，它设计出来是为了拿图片尺寸，不是用来判毒的。

4.4 这个等级真正想教的东西

回过头看，High等级的三道检查里，真正起决定作用的是哪一道？我的判断是重命名。扩展名白名单可以被各种边角情况影响，图像校验可以被文件头欺骗，但只要文件名和扩展名都被服务端彻底接管，攻击者就失去了对"文件最终叫什么、是什么类型"的控制权，绝大多数利用路径直接断掉。

这个结论可以推广成一条设计原则：在文件上传这条链路上，凡是客户端能控制的东西，都不能作为安全判断的依据。文件名、扩展名、MIME、大小、甚至文件内容的一部分，全都属于"客户端可控制"的范畴。服务端唯一能真正信任的，是自己重新计算、重新生成的那部分结果。

所以正确的做法顺序是：先把文件收进临时位置，用自己的逻辑重新判定类型（读文件头魔数、用完整解析库），然后用自己的规则重新生成文件名和扩展名，最后把它放到一个明确禁止解析的目录里。这四步里每一步都在剥夺客户端的控制权，比堆一堆校验函数有效得多。

实操心得：做High等级实验时，建议你把重命名后的文件名记下来，顺便观察哈希值的构成。md5(uniqid() . 原文件名)这种写法意味着同一文件多次上传会得到不同名字，这在实际业务里是好事——避免覆盖、避免猜测。我在给项目做评审时，看到上传文件名还保留原始名字的，基本可以直接标一个中危。

5. Impossible等级：防御该怎么写才算合格

5.1 源码里的组合拳：扩展名、MIME、图像、重编码

Impossible等级把前面所有检查合并到一起，并且加上了最关键的一步：重新编码。它不是在原文件上做校验，而是把上传的临时文件当作图像读进内存，重新生成一张干净的图，再写到目标位置。这个动作会把文件里所有非图像数据——包括追加的代码、注释块里藏的元数据——统统丢掉。

<?php if( isset( $_POST[ 'Upload' ] ) ) { $target_path = DVWA_WEB_PAGE_TO_ROOT . "hackable/uploads/"; $uploaded_name = $_FILES[ 'uploaded' ][ 'name' ]; $uploaded_ext = strtolower( substr( $uploaded_name, strrpos( $uploaded_name, '.' ) + 1 ) ); $uploaded_size = $_FILES[ 'uploaded' ][ 'size' ]; $uploaded_type = $_FILES[ 'uploaded' ][ 'type' ]; $uploaded_tmp = $_FILES[ 'uploaded' ][ 'tmp_name' ]; if( ( $uploaded_ext == "jpg" || $uploaded_ext == "jpeg" || $uploaded_ext == "png" ) && ( $uploaded_size < 100000 ) && ( $uploaded_type == 'image/jpeg' || $uploaded_type == 'image/png' ) && getimagesize( $uploaded_tmp ) ) { // 读入临时文件，重建图像资源 if( $uploaded_type == 'image/png' ) { $temp_image = imagecreatefrompng( $uploaded_tmp ); } else { $temp_image = imagecreatefromjpeg( $uploaded_tmp ); } // 用随机名写到目标位置，写入的是重新编码后的像素数据 $target_path .= md5( uniqid() . $uploaded_name ) . '.' . $uploaded_ext; if( $uploaded_type == 'image/png' ) { imagepng( $temp_image, $target_path ); } else { imagejpeg( $temp_image, $target_path, 100 ); } imagedestroy( $temp_image ); echo "<pre>{$target_path} succesfully uploaded!</pre>"; } else { echo '<pre>Your image was not uploaded. We can only accept JPEG or PNG images.</pre>'; } } ?>

这段代码值得逐行体会。扩展名白名单、大小、MIME、图像校验四道检查全在，任何一道不过直接拒。通过之后，文件不是被"搬"过去，而是被"重建"出来。imagecreatefromjpeg解析像素矩阵，imagejpeg重新编码输出，中间那一层原始字节被彻底丢弃。你追加在图片末尾的任何内容，到这里全部消失。

这一步的防御强度是质变级的。前面所有等级里，"文件内容里带了什么"始终是个变量；到这一级，落盘的文件内容完全由服务端重新生成，攻击者无从影响。我个人的评价是：重编码是文件上传防御里性价比最高的一招，代码量不大，效果极其彻底，代价只是轻微的画质损失和一点CPU开销。

5.2 从靶场抄到生产环境的一份防护清单

靶场代码终究是教学版本，直接抄到生产会遇到几个现实问题。我把自己项目里实际用的一套检查顺序整理出来，按执行先后排列，越靠前的越便宜，越靠后的越贵：

1. 入口前先卡权限。上传接口必须有登录态校验和频次限制。很多上传滥用问题根本不是代码漏洞，是接口裸奔。
2. 卡请求体总大小。在Web服务器层面设一个上限，比如单请求不超过10MB。这一层挡掉的是资源耗尽类问题，比应用层判断便宜得多。
3. 卡扩展名白名单。用服务端自己的逻辑取扩展名，转小写，全等比对白名单，不在列表里直接拒。列表要短，只放业务真正需要的类型。
4. 卡声明的MIME。虽然它不可信，但作为第一道粗筛还是有价值的，能挡掉大量随手构造的请求。
5. 用文件头魔数判真实类型。读文件前若干字节，对照已知格式的特征值。这一步才是真正的类型判定，不能用客户端声明的值代替。
6. 完整解析一次文件。图片用图像库解析，文档用对应的解析库打开。解析失败一律拒绝。这一步能挡掉大量畸形文件。
7. 重新编码或重新生成。图片走重编码，文档走格式转换，实在没有重编码能力的类型，至少要剥离全部元数据。
8. 服务端生成文件名。哈希、UUID都行，就是不能保留原始名，也不能让用户指定路径。扩展名由服务端根据判定结果确定。
9. 落到禁止解析的目录。这一步是架构层的兜底，下面单独讲。

这九步里，第5、6、7步解决的是"内容真实性"，第8步解决的是"客户端控制权"，第9步解决的是"存储环境"。三条腿缺一条，防线就是瘸的。

注意：白名单列表不要图省事写成黑名单的补集。业务扩展名清单是会变的，写成白名单意味着每次变更都要走评审，这恰恰是你想要的——上传类型的扩展应该是一次有意识的安全决策，而不是随手加一行。

5.3 服务器与目录配置层面的兜底

代码写得再好，部署姿势错了照样白搭。这一块我在实际项目里踩过的坑比代码层还多，说几个关键的。

上传目录必须禁止脚本解析。在Web服务器配置里，把上传目录的脚本处理器关掉，或者干脆给这个目录单独设一段配置，明确它只提供静态文件。这一步的收益巨大——即使有一天代码校验被绕过了，落进去的文件也执行不了，最坏结果是"占点存储空间"而不是"服务器失守"。

上传目录和业务代码目录物理隔离。上传的文件不要放在代码目录的子目录里，更不要放在能被包含函数直接访问的位置。理想情况是上传走独立的存储服务或独立域名，业务侧只存引用路径。这个改造在项目初期做成本很低，上线后再改要动一堆地方。

目录权限收窄。上传目录对Web进程只需要写权限，不需要执行权限；对业务读取只需要读权限，不需要写。Linux下的权限位设成类似755目录、644文件这种保守组合，别图省事给777。

禁止目录列表。上传目录如果开了自动索引，攻击者不用猜名字就能看到你所有的文件。这个配置默认往往是关的，但换环境、换版本的时候容易被意外打开，建议在部署检查清单里明确写上。

文件名与路径彻底服务端化。不要接受客户端传来的任何路径成分，不要做"按用户ID建子目录"之外的任何路径拼接。路径拼接是路径穿越的温床，能不拼就不拼。

这几条加起来，就是我在给项目做上传功能评审时的固定检查项。经验上，代码层问题修复快但容易反复，配置层问题一旦修好基本不会回归。所以配置这块的投入回报比其实更高。

6. 实验常见问题与排查实录

6.1 传上去了却访问不到

这是这个模块里出现频率最高的现象，我把它拆成三层来排查，顺序从便宜到贵。

第一层查路径本身。回显的路径是完整的URL还是相对路径？复制的时候有没有漏掉段？有没有因为编码问题导致路径里的字符被转义？我遇到过最离谱的一次是路径里有个空格被自动编码成了%20，访问就直接404，查了半小时。

第二层查文件是否真的落盘。如果你在容器里跑靶场，进容器看一眼上传目录里到底有没有这个文件。文件名是不是被重命名了，扩展名对不对，大小是不是0字节。0字节这个情况很常见，通常是临时目录权限不对或者move_uploaded_file失败但没有报错。

第三层查解析配置。文件在、路径对，但访问出来是源码原文，说明这个扩展名没有被交给脚本解析器。这时候去查Web服务器的处理器配置，看上传目录下的该扩展名是否被正确映射。如果是"访问直接下载文件"，那是响应头的问题，通常是服务器没识别这个类型。

我整理了一个速查表，遇到现象直接对号入座：

6.2 常见报错与现象速查表

除了上面那张，还有几类属于"看起来像报错其实是设计如此"的情况，新手很容易被绕进去。

一类是空响应或者500。多半是服务端处理时抛了异常而错误信息没被显示出来。这时候去看服务器的错误日志，比在页面上瞎点快得多。容器化环境里一行命令就能看到日志，这是容器方式跑靶场最大的便利。

另一类是上传成功但重命名后找不到文件。High和Impossible等级都会重命名，回显里给的就是新名字，直接复制那个路径访问即可，别拿原始文件名去猜。我见过有人拿upload-ok.jpg去访问，当然404。

还有一类是改了MIME依然被拒。除了前面说的改错位置，还有一种情况是浏览器对某些扩展名本身就带着固定的分段类型，你在代理工具里改完之后如果触发了新的请求（比如页面刷新重传），改动就丢了。养成"改完立刻放行、不刷新页面"的习惯。

6.3 实验收尾：清理、复现记录与合规

实验做完别急着关环境，有三件事值得做。第一，清空上传目录。累积的文件会让你下次实验时对着目录发呆，分不清哪个是这次的。容器化环境直接销毁重建最省事。第二，把四个等级的源码差异整理成一份自己的对照笔记。不是为了记住结论，而是为了记住"每一步为什么要加这个检查"。第三，记录一条完整的复现链路，从请求到响应到访问结果，图文都留。这份记录在你向别人解释防御逻辑时，比任何文档都有说服力。

最后说说边界这件事。这个模块的四个等级，本质上是一份防御教材。你在里面学到的每一个绕过手法，都对应着一条防御要求；你越熟悉绕过的路径，写防护时就越知道该在哪堵。我带人练这个模块时，最后一课永远是让他们关掉靶场，去翻一个自己熟悉的项目的上传接口，看看九条检查里缺了几条。这个动作比再刷十遍靶场有价值得多。

我个人在实操中最深的一个体会是：文件上传这个问题，看起来是"校验写没写全"，实际上是"信任边界划没划清"。代码里只要出现一个来自客户端的值参与了安全判断，或者落盘位置的选择没有经过安全考量，这条链上就总有一处会松。把这两件事守住，剩下的都是细节。