1. 从靶场通关到代码审计一次完整的文件上传漏洞实战复盘最近在整理安全学习笔记翻到了之前通关Upload-labs靶场的记录。这个靶场在Web安全入门圈子里名气不小它把文件上传漏洞的各种花式绕过姿势从最基础的前端校验到复杂的条件竞争打包成了21个关卡。很多人通关后可能就止步于“知道怎么绕过”但我觉得真正有价值的部分在于通关之后——去翻看每一关的源代码理解防御者到底是怎么想的漏洞又是如何被精心构造出来的。这就像解谜游戏知道了答案还不够得明白出题人设置陷阱的逻辑下次遇到真实环境才能举一反三。今天我就结合自己的通关笔记和代码审计过程把这21关里藏着的门道掰开揉碎了讲清楚希望能给正在入门Web安全的朋友们一条清晰的实战路径。2. 环境搭建与基础认知你的第一道防线是如何被突破的在开始闯关之前一个稳定的实验环境是基石。Upload-labs通常使用PHPApache/MySQL的环境你可以用PHPStudy、XAMPP或者Docker快速搭建。我个人的习惯是用Docker因为环境隔离干净复现起来也方便。这里给出一个简单的Docker-compose配置作为参考version: 3 services: upload-labs: image: vulhub/upload-labs:latest ports: - 8080:80 volumes: - ./uploads:/var/www/html/upload # 映射上传目录方便查看上传结果部署完成后访问http://localhost:8080就能看到靶场界面。前几关看似简单却是理解文件上传漏洞本质的关键。2.1 第一关前端JS校验的脆弱性这一关的页面看起来很正常选择文件点击上传。但如果你尝试上传一个.php后缀的文件页面可能会直接弹窗提示“文件类型不正确”文件甚至没有发往服务器。绕过姿势与原理 这种防御完全依赖于浏览器端执行的JavaScript代码。它的校验逻辑通常是检查文件名后缀是否在白名单如.jpg, .png内。绕过方法极其简单禁用浏览器JS在浏览器设置中临时禁用JavaScript然后直接上传。抓包改包使用Burp Suite这类代理工具拦截浏览器发出的HTTP请求。即使前端提示错误请求依然可能被发出并被拦截。在拦截到的请求中直接将文件名shell.php改为shell.jpg然后放行服务器端因为没有任何校验就会直接保存.php文件。代码审计视角 查看这一关的源代码通常是pass-01.php你会发现服务器端代码可能只有简单的文件移动操作如move_uploaded_file()而没有任何关于文件类型、内容的检查逻辑。防御完全交给了前端这在实际开发中是严重的安全误区。前端校验用于提升用户体验但绝不能作为安全防线。2.2 第二关MIME类型校验的欺骗过了第一关靶场在第二关学“聪明”了它开始检查HTTP请求头中的Content-Type字段。当你上传一个图片时这个值通常是image/jpeg或image/png而上传一个PHP文件时则是text/php或application/octet-stream。服务器端代码会检查这个值是否在图片类型的白名单里。绕过姿势与原理 既然校验的是请求头那我们就在传输过程中修改它。步骤同样依赖抓包正常选择一个.php文件上传。用Burp Suite拦截上传请求。在Raw视图下找到Content-Type: application/octet-stream这一行将其修改为Content-Type: image/jpeg。放行请求即可绕过校验。代码审计视角 查看pass-02.php你会看到类似这样的代码if ($_FILES[upload_file][type] image/jpeg || $_FILES[upload_file][type] image/png) { // 允许上传 } else { $msg 文件类型不正确请上传jpgpng格式的图片; }这里的$_FILES[upload_file][type]获取的就是客户端发送的Content-Type它完全由客户端控制因此不可信。可靠的校验必须基于服务器端获取到的文件真实内容。2.3 第三关黑名单扩展名校验及其绕过从第三关开始防御移到了服务器端并且使用了黑名单机制。所谓黑名单就是定义一个不允许上传的文件后缀列表如[php, asp, jsp]。如果上传文件的后缀不在这个名单里就允许上传。经典绕过姿势 黑名单永远无法做到百分百覆盖尤其对于像Apache这样的Web服务器其文件解析特性会带来多种绕过机会特殊可解析后缀.php3,.php4,.php5,.phtml。这些后缀在Apache的某些配置下依然会被当作PHP脚本来解析。这是因为Apache的配置文件httpd.conf或.htaccess中可能有这样的指令AddType application/x-httpd-php .php .php3 .php4 .php5 .phtml。大小写绕过如果黑名单校验是区分大小写的且未做统一小写处理那么.Php,.pHp这样的后缀就可能绕过对.php的检查。点号绕过在文件名后添加一个点如shell.php.。Windows系统在保存文件时会自动去除末尾的点最终文件名为shell.php。空格绕过在文件名后添加一个空格如shell.php。同样Windows系统会去除末尾空格。如果后端代码使用$_FILES[file][name]获取文件名后未做修剪trim而保存时系统自动处理就会导致绕过。双写后缀绕过如果后端代码使用了简单的字符串替换如str_replace(‘.php’, ‘’, $filename)那么shell.pphphp经过替换后中间的php被移除两边的字符拼接起来又变成了shell.php。代码审计视角 审计pass-03.php核心代码可能如下$deny_ext array(.php,.asp,.jsp); $file_ext strtolower(substr($_FILES[upload_file][name], strrpos($_FILES[upload_file][name],.))); if(!in_array($file_ext, $deny_ext)) { // 保存文件 }这段代码有几个问题首先黑名单$deny_ext可能不全其次它使用了strtolower防止了大小写绕过但未处理点、空格、双写等问题。更关键的是它没有考虑服务器解析特性。3. 白名单的挑战与解析漏洞利用经历了黑名单的种种绕过开发者可能会转向更安全的策略——白名单。只允许上传指定的、安全的文件类型如.jpg,.png,.gif。这看起来固若金汤但依然存在突破口。3.1 第四关.htaccess文件攻击如果服务器是Apache且目标上传目录允许用户上传.htaccess文件并且该目录的配置允许覆盖AllowOverride All或AllowOverride Options FileInfo那么攻击将变得非常直接。.htaccess文件的作用 这个文件是Apache的分布式配置文件可以覆盖其所在目录及子目录的服务器配置。攻击者可以上传一个内容如下的.htaccess文件AddType application/x-httpd-php .jpg这条指令告诉Apache在当前目录下所有.jpg文件都应被当作PHP脚本来解析。之后攻击者再上传一个包含恶意代码的shell.jpg文件访问它时其中的PHP代码就会被执行。绕过姿势首先需要判断目标上传目录是否有写入.htaccess文件的权限。可以尝试上传一个无害的文本文件测试。如果可写先上传上述内容的.htaccess文件。再上传包含WebShell代码的shell.jpg文件。访问http://target.com/upload/shell.jpg即可触发代码执行。代码审计与防御 审计时要检查服务器是否限制了.htaccess文件的上传或者是否禁用了目标目录的AllowOverride配置。防御上除了严格的白名单校验还应确保上传目录无执行权限且服务器配置安全。3.2 第五关IIS 6.0解析漏洞历史但经典这一关模拟的是旧版本IIS服务器6.0的一个著名解析漏洞。虽然现在已不常见但理解它有助于掌握“解析逻辑”这个核心概念。漏洞原理 IIS 6.0在解析文件路径时存在两个缺陷目录名解析当路径中存在类似*.asp的目录名时该目录下的所有文件都会被当作ASP脚本来解析。例如上传文件到/upload/shell.asp/logo.jpglogo.jpg会被当作ASP文件执行。分号解析IIS 6.0在解析文件名时会将分号;后的内容截断。例如文件shell.asp;.jpg会被IIS解析为shell.asp并执行而绕过基于.jpg后缀的白名单检查。绕过姿势上传一个名为shell.asp;.jpg的文件。或者如果能够控制上传路径尝试创建类似xxx.asp的目录并将文件上传至该目录下。代码审计视角 这个漏洞的成因在于Web服务器自身的解析逻辑错误与应用层代码关系不大。审计时需要关注的是服务器环境。对于现代应用更应关注Nginx、Apache的某些错误配置导致的解析漏洞。3.3 第六关Nginx/PHP解析漏洞错误配置这是一个常见的错误配置场景主要发生在Nginx PHP-FPM或FastCGI的架构下。漏洞原理 Nginx的配置文件可能如下location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; ... }这条规则的意思是所有以.php结尾的URL请求都会交给后端的PHP解释器处理。问题出在下面这个配置上location /upload/ { ... }如果/upload/目录的location块中没有单独定义对PHP文件的处理规则那么当请求一个不存在的.php文件时Nginx会按顺序继续匹配其他location。一个危险的配置是使用了try_files指令或错误配置了fastcgi_split_path_info。经典攻击路径 假设存在一个上传文件shell.jpg其内容包含PHP代码。攻击者访问http://target.com/upload/shell.jpg/.phpNginx看到这个URL路径是/upload/shell.jpg/.php。它先匹配到/upload/的规则没找到对.php的特殊处理于是将文件shell.jpg作为静态文件读取。但由于路径末尾有/.php在某种错误配置下如fastcgi_split_path_info正则匹配不当Nginx可能会错误地将整个路径shell.jpg/.php传递给PHP-FPM。PHP-FPM在解析时会取PATH_INFO即/.php之前的shell.jpg作为要执行的文件从而导致shell.jpg中的PHP代码被执行。代码审计与防御 这个漏洞根源在于Nginx配置而非应用代码。但开发者在设计时应有安全意识确保上传目录被配置为纯静态资源目录禁止任何脚本执行。在Nginx配置中可以为上传目录单独添加一条规则location ^~ /upload/ { deny all; # 或者只允许静态文件访问禁止PHP解析 location ~ \.php$ { deny all; } }4. 内容校验、竞争条件与终极绕过当后缀、MIME、服务器解析漏洞都被堵上后防御者会祭出更强大的武器检查文件内容本身以及使用条件竞争等复杂逻辑。这也是Upload-labs后续关卡的精髓所在。4.1 第七关文件头Magic Bytes校验这是比检查后缀更可靠的方法。图片文件如JPEG、PNG在文件开头有固定的字节序列称为“魔数”Magic Bytes。例如JPEG:FF D8 FF E0或FF D8 FF E1PNG:89 50 4E 47 0D 0A 1A 0A服务器端PHP代码可以使用getimagesize()函数或直接读取文件头来判断一个文件是否为真实的图片。绕过姿势制作图片马既然要检查文件头那我们就给WebShell加上一个合法的图片头。准备一个正常的图片文件如test.jpg和一个PHP WebShell文件如shell.php。在Linux下使用命令合成cat test.jpg shell.php webshell.jpg这样生成的文件文件头是合法的JPEG格式能通过getimagesize()的检查但文件末尾附带了PHP代码。利用方式 仅仅上传成功还不够需要让服务器以PHP方式解析这个文件。这就需要结合之前的漏洞文件包含漏洞LFI如果网站存在本地文件包含漏洞例如include($_GET[‘file’])那么攻击者可以传入?fileupload/webshell.jpg服务器在包含时会将其作为PHP代码执行因为include函数不关心后缀只关心文件内容。解析漏洞如果存在第三节所述的解析漏洞也可能直接解析。代码审计视角 查看使用getimagesize()的关卡代码。这个函数本身是可靠的但它只检查文件头。防御的短板在于后续的解析环节。安全的做法是即使验证了是图片也应重命名文件如使用随机字符串.jpg后缀并避免将用户上传的文件放在Web可访问目录或者确保该目录绝无脚本执行权限。4.2 第八关条件竞争漏洞Race Condition这是文件上传漏洞中非常巧妙和危险的一种利用了程序“检查”和“保存”两个动作之间的时间差。漏洞原理 一个看似安全的代码逻辑可能是这样的检查文件后缀是否在白名单.jpg内。检查文件内容如getimagesize()是否为图片。如果都通过将文件从临时位置移动到最终存储位置。移动后为了防止脚本执行将文件重命名在文件名后添加.jpg后缀例如$filename $file . ‘.jpg’。问题出在第3步和第4步之间。假设攻击者上传了一个内容为?php fputs(fopen(‘shell.php’, ‘w’), ‘?php eval($_POST[cmd]);?’);?的.jpg文件。这个文件能通过前两步检查。在文件被移动到最终目录假设路径为/upload/temp_abc123但尚未被重命名为.jpg的极短时间窗口内这个文件是存在的并且没有.jpg后缀。如果攻击者能以极快的速度并发地访问这个文件/upload/temp_abc123那么其中的PHP代码就会被执行。一旦代码执行它会在服务器上写入一个全新的、完整的WebShell文件shell.php。这个新生成的文件与上传逻辑无关因此不受任何上传校验的限制。攻击模拟 攻击者需要编写一个自动化脚本在上传请求发出的同时以极高的频率例如每秒数百次去访问那个可能存在的临时文件路径。由于无法精确知道临时文件名攻击可能需要大量尝试。代码审计视角 审计此类漏洞要寻找“检查-保存-二次处理”模式并且二次处理如重命名发生在保存之后。安全的做法应该是先在一个安全的位置如非Web目录完成所有校验和重命名操作再将最终安全的文件移动到Web可访问目录。或者使用原子性操作确保检查和保存的不可分割性。4.3 第九关及以上综合绕过与Windows特性后续关卡往往是前面多种防御手段的组合例如同时检查后缀黑/白名单、MIME类型、文件头甚至文件内容的一部分。绕过它们需要更细致的观察和组合拳。Windows系统特性利用 在一些关卡中可以巧妙利用Windows文件系统的一些特性流StreamWindows NTFS文件系统支持交替数据流ADS。例如可以上传一个名为shell.jpg::$DATA的文件。在某些处理逻辑下文件可能会被保存为shell.jpg从而绕过对.php的检查。但这种方式对服务器环境依赖性强在现代Web应用中较少能成功。特殊字符截断在PHP版本低于5.3.4且magic_quotes_gpc关闭的情况下0x00空字节在字符串中会被解释为终止符。例如上传文件名为shell.php%00.jpg经过某些解码或处理后服务器端获取到的文件名可能在%00处被截断最终认为是shell.php。这是历史漏洞但原理值得了解。代码审计的终极思维 通关所有21关后进行代码审计的目标不再是寻找某个单一的绕过点而是理解整个防御体系的逻辑链条。你需要像攻击者一样思考入口点用户可控的输入有哪些$_FILES[‘name’],$_FILES[‘type’],$_FILES[‘tmp_name’]校验链代码对这些输入做了哪些处理顺序是什么trim, strtolower, strrpos, in_array, getimagesize, 重命名逻辑…逻辑缺陷校验链是否存在顺序问题、遗漏步骤例如先去除空格再检查后缀就能防御空格绕过吗需要看去除空格后是否再次检查后缀环境依赖代码逻辑是否依赖于特定的服务器配置Apache解析、Nginx配置、操作系统Windows/Linux、PHP版本或设置magic_quotes_gpc最终处置文件被保存到哪里目录权限如何文件名是否随机化是否还有后续的解析或包含逻辑5. 从靶场到实战构建健壮的文件上传功能通过这21关的洗礼和对应的代码审计我们最终的目标是能够开发出真正安全的文件上传功能。以下是一些核心的安全实践总结1. 使用白名单而非黑名单 只允许一组确切的、安全的文件扩展名如.jpg,.png,.pdf。列表要尽可能小。2. 校验文件内容而非仅依赖元数据使用getimagesize()、exif_imagetype()或文件魔数检测来验证图片文件。对于其他类型如PDF可以使用相应的库进行解析验证。3. 重命名上传文件 不要使用用户提供的文件名。使用随机生成的字符串如UUID作为文件名并保留白名单验证过的扩展名。$extension strtolower(pathinfo($_FILES[file][name], PATHINFO_EXTENSION)); $allowed_ext [jpg, png, gif]; if (!in_array($extension, $allowed_ext)) { die(非法文件类型); } // 验证文件内容... $new_filename uniqid() . ‘.’ . $extension; move_uploaded_file($_FILES[‘file’][‘tmp_name’], ‘/safe/path/’ . $new_filename);4. 设置安全的存储位置将上传的文件存储在Web根目录之外。通过一个专门的脚本如download.php?idxxx来提供文件访问该脚本会进行额外的权限和类型检查。如果必须存储在Web目录下务必通过服务器配置如.htaccess,nginx.conf禁止该目录下的脚本执行。设置正确的文件权限如644。5. 限制文件大小 在服务器端php.ini中的upload_max_filesize和post_max_size和应用层同时进行限制。6. 使用防病毒软件扫描 对于允许上传文档的场景使用ClamAV等工具进行病毒扫描。7. 防范条件竞争将文件先保存到一个临时的、非Web访问的目录完成所有校验和重命名后再移动到最终位置。或者使用文件系统锁或数据库事务来确保操作的原子性。8. 持续更新与安全审计 关注所使用的第三方库、框架的安全更新。定期对上传功能进行安全审计和渗透测试。通关Upload-labs并完成代码审计就像完成了一次从攻击到防御的完整推演。它带给你的不仅是21种绕过技巧更重要的是一种深入代码逻辑、结合运行环境去系统性思考安全问题的能力。在真实环境中漏洞往往隐藏在意想不到的逻辑组合或配置疏忽中。养成代码审计的习惯能让你在开发时更早地发现潜在风险在渗透测试时更快地定位问题根源。
文件上传漏洞攻防实战：从靶场通关到代码审计的21个核心要点
发布时间：2026/8/2 14:09:06
1. 从靶场通关到代码审计一次完整的文件上传漏洞实战复盘最近在整理安全学习笔记翻到了之前通关Upload-labs靶场的记录。这个靶场在Web安全入门圈子里名气不小它把文件上传漏洞的各种花式绕过姿势从最基础的前端校验到复杂的条件竞争打包成了21个关卡。很多人通关后可能就止步于“知道怎么绕过”但我觉得真正有价值的部分在于通关之后——去翻看每一关的源代码理解防御者到底是怎么想的漏洞又是如何被精心构造出来的。这就像解谜游戏知道了答案还不够得明白出题人设置陷阱的逻辑下次遇到真实环境才能举一反三。今天我就结合自己的通关笔记和代码审计过程把这21关里藏着的门道掰开揉碎了讲清楚希望能给正在入门Web安全的朋友们一条清晰的实战路径。2. 环境搭建与基础认知你的第一道防线是如何被突破的在开始闯关之前一个稳定的实验环境是基石。Upload-labs通常使用PHPApache/MySQL的环境你可以用PHPStudy、XAMPP或者Docker快速搭建。我个人的习惯是用Docker因为环境隔离干净复现起来也方便。这里给出一个简单的Docker-compose配置作为参考version: 3 services: upload-labs: image: vulhub/upload-labs:latest ports: - 8080:80 volumes: - ./uploads:/var/www/html/upload # 映射上传目录方便查看上传结果部署完成后访问http://localhost:8080就能看到靶场界面。前几关看似简单却是理解文件上传漏洞本质的关键。2.1 第一关前端JS校验的脆弱性这一关的页面看起来很正常选择文件点击上传。但如果你尝试上传一个.php后缀的文件页面可能会直接弹窗提示“文件类型不正确”文件甚至没有发往服务器。绕过姿势与原理 这种防御完全依赖于浏览器端执行的JavaScript代码。它的校验逻辑通常是检查文件名后缀是否在白名单如.jpg, .png内。绕过方法极其简单禁用浏览器JS在浏览器设置中临时禁用JavaScript然后直接上传。抓包改包使用Burp Suite这类代理工具拦截浏览器发出的HTTP请求。即使前端提示错误请求依然可能被发出并被拦截。在拦截到的请求中直接将文件名shell.php改为shell.jpg然后放行服务器端因为没有任何校验就会直接保存.php文件。代码审计视角 查看这一关的源代码通常是pass-01.php你会发现服务器端代码可能只有简单的文件移动操作如move_uploaded_file()而没有任何关于文件类型、内容的检查逻辑。防御完全交给了前端这在实际开发中是严重的安全误区。前端校验用于提升用户体验但绝不能作为安全防线。2.2 第二关MIME类型校验的欺骗过了第一关靶场在第二关学“聪明”了它开始检查HTTP请求头中的Content-Type字段。当你上传一个图片时这个值通常是image/jpeg或image/png而上传一个PHP文件时则是text/php或application/octet-stream。服务器端代码会检查这个值是否在图片类型的白名单里。绕过姿势与原理 既然校验的是请求头那我们就在传输过程中修改它。步骤同样依赖抓包正常选择一个.php文件上传。用Burp Suite拦截上传请求。在Raw视图下找到Content-Type: application/octet-stream这一行将其修改为Content-Type: image/jpeg。放行请求即可绕过校验。代码审计视角 查看pass-02.php你会看到类似这样的代码if ($_FILES[upload_file][type] image/jpeg || $_FILES[upload_file][type] image/png) { // 允许上传 } else { $msg 文件类型不正确请上传jpgpng格式的图片; }这里的$_FILES[upload_file][type]获取的就是客户端发送的Content-Type它完全由客户端控制因此不可信。可靠的校验必须基于服务器端获取到的文件真实内容。2.3 第三关黑名单扩展名校验及其绕过从第三关开始防御移到了服务器端并且使用了黑名单机制。所谓黑名单就是定义一个不允许上传的文件后缀列表如[php, asp, jsp]。如果上传文件的后缀不在这个名单里就允许上传。经典绕过姿势 黑名单永远无法做到百分百覆盖尤其对于像Apache这样的Web服务器其文件解析特性会带来多种绕过机会特殊可解析后缀.php3,.php4,.php5,.phtml。这些后缀在Apache的某些配置下依然会被当作PHP脚本来解析。这是因为Apache的配置文件httpd.conf或.htaccess中可能有这样的指令AddType application/x-httpd-php .php .php3 .php4 .php5 .phtml。大小写绕过如果黑名单校验是区分大小写的且未做统一小写处理那么.Php,.pHp这样的后缀就可能绕过对.php的检查。点号绕过在文件名后添加一个点如shell.php.。Windows系统在保存文件时会自动去除末尾的点最终文件名为shell.php。空格绕过在文件名后添加一个空格如shell.php。同样Windows系统会去除末尾空格。如果后端代码使用$_FILES[file][name]获取文件名后未做修剪trim而保存时系统自动处理就会导致绕过。双写后缀绕过如果后端代码使用了简单的字符串替换如str_replace(‘.php’, ‘’, $filename)那么shell.pphphp经过替换后中间的php被移除两边的字符拼接起来又变成了shell.php。代码审计视角 审计pass-03.php核心代码可能如下$deny_ext array(.php,.asp,.jsp); $file_ext strtolower(substr($_FILES[upload_file][name], strrpos($_FILES[upload_file][name],.))); if(!in_array($file_ext, $deny_ext)) { // 保存文件 }这段代码有几个问题首先黑名单$deny_ext可能不全其次它使用了strtolower防止了大小写绕过但未处理点、空格、双写等问题。更关键的是它没有考虑服务器解析特性。3. 白名单的挑战与解析漏洞利用经历了黑名单的种种绕过开发者可能会转向更安全的策略——白名单。只允许上传指定的、安全的文件类型如.jpg,.png,.gif。这看起来固若金汤但依然存在突破口。3.1 第四关.htaccess文件攻击如果服务器是Apache且目标上传目录允许用户上传.htaccess文件并且该目录的配置允许覆盖AllowOverride All或AllowOverride Options FileInfo那么攻击将变得非常直接。.htaccess文件的作用 这个文件是Apache的分布式配置文件可以覆盖其所在目录及子目录的服务器配置。攻击者可以上传一个内容如下的.htaccess文件AddType application/x-httpd-php .jpg这条指令告诉Apache在当前目录下所有.jpg文件都应被当作PHP脚本来解析。之后攻击者再上传一个包含恶意代码的shell.jpg文件访问它时其中的PHP代码就会被执行。绕过姿势首先需要判断目标上传目录是否有写入.htaccess文件的权限。可以尝试上传一个无害的文本文件测试。如果可写先上传上述内容的.htaccess文件。再上传包含WebShell代码的shell.jpg文件。访问http://target.com/upload/shell.jpg即可触发代码执行。代码审计与防御 审计时要检查服务器是否限制了.htaccess文件的上传或者是否禁用了目标目录的AllowOverride配置。防御上除了严格的白名单校验还应确保上传目录无执行权限且服务器配置安全。3.2 第五关IIS 6.0解析漏洞历史但经典这一关模拟的是旧版本IIS服务器6.0的一个著名解析漏洞。虽然现在已不常见但理解它有助于掌握“解析逻辑”这个核心概念。漏洞原理 IIS 6.0在解析文件路径时存在两个缺陷目录名解析当路径中存在类似*.asp的目录名时该目录下的所有文件都会被当作ASP脚本来解析。例如上传文件到/upload/shell.asp/logo.jpglogo.jpg会被当作ASP文件执行。分号解析IIS 6.0在解析文件名时会将分号;后的内容截断。例如文件shell.asp;.jpg会被IIS解析为shell.asp并执行而绕过基于.jpg后缀的白名单检查。绕过姿势上传一个名为shell.asp;.jpg的文件。或者如果能够控制上传路径尝试创建类似xxx.asp的目录并将文件上传至该目录下。代码审计视角 这个漏洞的成因在于Web服务器自身的解析逻辑错误与应用层代码关系不大。审计时需要关注的是服务器环境。对于现代应用更应关注Nginx、Apache的某些错误配置导致的解析漏洞。3.3 第六关Nginx/PHP解析漏洞错误配置这是一个常见的错误配置场景主要发生在Nginx PHP-FPM或FastCGI的架构下。漏洞原理 Nginx的配置文件可能如下location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; ... }这条规则的意思是所有以.php结尾的URL请求都会交给后端的PHP解释器处理。问题出在下面这个配置上location /upload/ { ... }如果/upload/目录的location块中没有单独定义对PHP文件的处理规则那么当请求一个不存在的.php文件时Nginx会按顺序继续匹配其他location。一个危险的配置是使用了try_files指令或错误配置了fastcgi_split_path_info。经典攻击路径 假设存在一个上传文件shell.jpg其内容包含PHP代码。攻击者访问http://target.com/upload/shell.jpg/.phpNginx看到这个URL路径是/upload/shell.jpg/.php。它先匹配到/upload/的规则没找到对.php的特殊处理于是将文件shell.jpg作为静态文件读取。但由于路径末尾有/.php在某种错误配置下如fastcgi_split_path_info正则匹配不当Nginx可能会错误地将整个路径shell.jpg/.php传递给PHP-FPM。PHP-FPM在解析时会取PATH_INFO即/.php之前的shell.jpg作为要执行的文件从而导致shell.jpg中的PHP代码被执行。代码审计与防御 这个漏洞根源在于Nginx配置而非应用代码。但开发者在设计时应有安全意识确保上传目录被配置为纯静态资源目录禁止任何脚本执行。在Nginx配置中可以为上传目录单独添加一条规则location ^~ /upload/ { deny all; # 或者只允许静态文件访问禁止PHP解析 location ~ \.php$ { deny all; } }4. 内容校验、竞争条件与终极绕过当后缀、MIME、服务器解析漏洞都被堵上后防御者会祭出更强大的武器检查文件内容本身以及使用条件竞争等复杂逻辑。这也是Upload-labs后续关卡的精髓所在。4.1 第七关文件头Magic Bytes校验这是比检查后缀更可靠的方法。图片文件如JPEG、PNG在文件开头有固定的字节序列称为“魔数”Magic Bytes。例如JPEG:FF D8 FF E0或FF D8 FF E1PNG:89 50 4E 47 0D 0A 1A 0A服务器端PHP代码可以使用getimagesize()函数或直接读取文件头来判断一个文件是否为真实的图片。绕过姿势制作图片马既然要检查文件头那我们就给WebShell加上一个合法的图片头。准备一个正常的图片文件如test.jpg和一个PHP WebShell文件如shell.php。在Linux下使用命令合成cat test.jpg shell.php webshell.jpg这样生成的文件文件头是合法的JPEG格式能通过getimagesize()的检查但文件末尾附带了PHP代码。利用方式 仅仅上传成功还不够需要让服务器以PHP方式解析这个文件。这就需要结合之前的漏洞文件包含漏洞LFI如果网站存在本地文件包含漏洞例如include($_GET[‘file’])那么攻击者可以传入?fileupload/webshell.jpg服务器在包含时会将其作为PHP代码执行因为include函数不关心后缀只关心文件内容。解析漏洞如果存在第三节所述的解析漏洞也可能直接解析。代码审计视角 查看使用getimagesize()的关卡代码。这个函数本身是可靠的但它只检查文件头。防御的短板在于后续的解析环节。安全的做法是即使验证了是图片也应重命名文件如使用随机字符串.jpg后缀并避免将用户上传的文件放在Web可访问目录或者确保该目录绝无脚本执行权限。4.2 第八关条件竞争漏洞Race Condition这是文件上传漏洞中非常巧妙和危险的一种利用了程序“检查”和“保存”两个动作之间的时间差。漏洞原理 一个看似安全的代码逻辑可能是这样的检查文件后缀是否在白名单.jpg内。检查文件内容如getimagesize()是否为图片。如果都通过将文件从临时位置移动到最终存储位置。移动后为了防止脚本执行将文件重命名在文件名后添加.jpg后缀例如$filename $file . ‘.jpg’。问题出在第3步和第4步之间。假设攻击者上传了一个内容为?php fputs(fopen(‘shell.php’, ‘w’), ‘?php eval($_POST[cmd]);?’);?的.jpg文件。这个文件能通过前两步检查。在文件被移动到最终目录假设路径为/upload/temp_abc123但尚未被重命名为.jpg的极短时间窗口内这个文件是存在的并且没有.jpg后缀。如果攻击者能以极快的速度并发地访问这个文件/upload/temp_abc123那么其中的PHP代码就会被执行。一旦代码执行它会在服务器上写入一个全新的、完整的WebShell文件shell.php。这个新生成的文件与上传逻辑无关因此不受任何上传校验的限制。攻击模拟 攻击者需要编写一个自动化脚本在上传请求发出的同时以极高的频率例如每秒数百次去访问那个可能存在的临时文件路径。由于无法精确知道临时文件名攻击可能需要大量尝试。代码审计视角 审计此类漏洞要寻找“检查-保存-二次处理”模式并且二次处理如重命名发生在保存之后。安全的做法应该是先在一个安全的位置如非Web目录完成所有校验和重命名操作再将最终安全的文件移动到Web可访问目录。或者使用原子性操作确保检查和保存的不可分割性。4.3 第九关及以上综合绕过与Windows特性后续关卡往往是前面多种防御手段的组合例如同时检查后缀黑/白名单、MIME类型、文件头甚至文件内容的一部分。绕过它们需要更细致的观察和组合拳。Windows系统特性利用 在一些关卡中可以巧妙利用Windows文件系统的一些特性流StreamWindows NTFS文件系统支持交替数据流ADS。例如可以上传一个名为shell.jpg::$DATA的文件。在某些处理逻辑下文件可能会被保存为shell.jpg从而绕过对.php的检查。但这种方式对服务器环境依赖性强在现代Web应用中较少能成功。特殊字符截断在PHP版本低于5.3.4且magic_quotes_gpc关闭的情况下0x00空字节在字符串中会被解释为终止符。例如上传文件名为shell.php%00.jpg经过某些解码或处理后服务器端获取到的文件名可能在%00处被截断最终认为是shell.php。这是历史漏洞但原理值得了解。代码审计的终极思维 通关所有21关后进行代码审计的目标不再是寻找某个单一的绕过点而是理解整个防御体系的逻辑链条。你需要像攻击者一样思考入口点用户可控的输入有哪些$_FILES[‘name’],$_FILES[‘type’],$_FILES[‘tmp_name’]校验链代码对这些输入做了哪些处理顺序是什么trim, strtolower, strrpos, in_array, getimagesize, 重命名逻辑…逻辑缺陷校验链是否存在顺序问题、遗漏步骤例如先去除空格再检查后缀就能防御空格绕过吗需要看去除空格后是否再次检查后缀环境依赖代码逻辑是否依赖于特定的服务器配置Apache解析、Nginx配置、操作系统Windows/Linux、PHP版本或设置magic_quotes_gpc最终处置文件被保存到哪里目录权限如何文件名是否随机化是否还有后续的解析或包含逻辑5. 从靶场到实战构建健壮的文件上传功能通过这21关的洗礼和对应的代码审计我们最终的目标是能够开发出真正安全的文件上传功能。以下是一些核心的安全实践总结1. 使用白名单而非黑名单 只允许一组确切的、安全的文件扩展名如.jpg,.png,.pdf。列表要尽可能小。2. 校验文件内容而非仅依赖元数据使用getimagesize()、exif_imagetype()或文件魔数检测来验证图片文件。对于其他类型如PDF可以使用相应的库进行解析验证。3. 重命名上传文件 不要使用用户提供的文件名。使用随机生成的字符串如UUID作为文件名并保留白名单验证过的扩展名。$extension strtolower(pathinfo($_FILES[file][name], PATHINFO_EXTENSION)); $allowed_ext [jpg, png, gif]; if (!in_array($extension, $allowed_ext)) { die(非法文件类型); } // 验证文件内容... $new_filename uniqid() . ‘.’ . $extension; move_uploaded_file($_FILES[‘file’][‘tmp_name’], ‘/safe/path/’ . $new_filename);4. 设置安全的存储位置将上传的文件存储在Web根目录之外。通过一个专门的脚本如download.php?idxxx来提供文件访问该脚本会进行额外的权限和类型检查。如果必须存储在Web目录下务必通过服务器配置如.htaccess,nginx.conf禁止该目录下的脚本执行。设置正确的文件权限如644。5. 限制文件大小 在服务器端php.ini中的upload_max_filesize和post_max_size和应用层同时进行限制。6. 使用防病毒软件扫描 对于允许上传文档的场景使用ClamAV等工具进行病毒扫描。7. 防范条件竞争将文件先保存到一个临时的、非Web访问的目录完成所有校验和重命名后再移动到最终位置。或者使用文件系统锁或数据库事务来确保操作的原子性。8. 持续更新与安全审计 关注所使用的第三方库、框架的安全更新。定期对上传功能进行安全审计和渗透测试。通关Upload-labs并完成代码审计就像完成了一次从攻击到防御的完整推演。它带给你的不仅是21种绕过技巧更重要的是一种深入代码逻辑、结合运行环境去系统性思考安全问题的能力。在真实环境中漏洞往往隐藏在意想不到的逻辑组合或配置疏忽中。养成代码审计的习惯能让你在开发时更早地发现潜在风险在渗透测试时更快地定位问题根源。
)
