Burp Suite实战：5种文件上传漏洞绕过姿势深度解析

1. 项目概述：从“改后缀”到“深度测试”的思维跃迁

在Web安全测试的日常工作中，文件上传漏洞的检测常常被新手简化为一个动作：把 .jpg 后缀改成 .php ，然后祈祷服务器能执行。如果失败，很多人就束手无策了。这种“改后缀”的初级操作，就像拿着一把钥匙去开所有的锁，成功率可想而知。今天，我们就以 SDcms （一个经典的ASP内容管理系统）为靶场，彻底告别这种浅尝辄止的测试方式。我将带你使用渗透测试的瑞士军刀—— Burp Suite ，深入剖析文件上传漏洞的5种核心绕过姿势。这不仅仅是几个技巧的罗列，更是一次从“脚本小子”到“深度测试者”的思维升级。无论你是刚接触Burp Suite的新手，还是想系统梳理文件上传攻防逻辑的安全爱好者，这篇文章都将为你提供一个清晰、可复现的实战路径。我们会从最基础的客户端校验绕过，一路深入到服务器端解析、逻辑缺陷等高级层面，让你真正理解漏洞背后的“为什么”，而不仅仅是“怎么做”。

2. 测试环境搭建与目标分析

2.1 靶场环境准备

要进行有效的深度测试，首先需要一个可控的、安全的实验环境。我们不建议也不支持对任何未经授权的在线系统进行测试。这里，我们使用一个经典的ASP集成环境（如WAMP或自行搭建的IIS+ASP环境），并部署一个存在已知文件上传漏洞的旧版本SDcms。你可以在一些开源漏洞靶场或历史版本存档中找到它。确保你的Burp Suite（社区版或专业版均可）已正确安装并配置好浏览器代理（通常是127.0.0.1:8080）。同时，在Burp的 Proxy -> Options 中，确保 Intercept 是关闭的，我们更多会用到 Repeater 和 Intruder 模块。将靶场地址加入到 Proxy -> Options -> Scope 中，可以避免捕获到无关流量。

2.2 SDcms上传点分析与常规测试

部署好SDcms后，我们首先需要定位其文件上传功能点。通常，这可能在后台的文章发布、头像上传、附件管理等模块。以管理员身份登录后台，找到一个允许上传文件（如图片、附件）的页面。打开浏览器开发者工具（F12）的 Network 面板，并开启 Preserve log 。尝试上传一个正常的图片文件（如 test.jpg ），观察浏览器发送的HTTP请求。你会发现，除了文件内容本身，请求头中通常包含 Content-Type （如 image/jpeg ），而请求体（body）中则包含了文件名、文件内容等关键信息。

接下来，进行最基础的测试：尝试直接上传一个WebShell文件（例如一个内容为 <%eval request(“cmd”)%> 的 shell.asp ）。绝大多数情况下，你会直接收到一个错误提示，如“文件类型不允许”或“禁止上传脚本文件”。这个结果恰恰是我们深度测试的起点。它告诉我们，目标系统至少存在一层防护。我们的任务就是利用Burp Suite，像外科手术一样，一层层剥离这些防护，找到那个可以让我们“通行”的缝隙。

3. 姿势一：前端JavaScript校验的绕过与流量拦截

3.1 原理剖析：为什么“改后缀”会失败？

很多Web应用，包括一些版本的SDcms，会在用户选择文件后、点击上传按钮前，通过一段嵌入在页面中的JavaScript代码来校验文件的后缀名。这段代码通常会获取文件名，检查其是否在以 .jpg 、 .png 、 .gif 等结尾的白名单中。如果不符合，则弹出一个警告框（例如“请上传图片格式文件”），并阻止表单的提交。这就是最典型的 客户端校验 。它的致命弱点在于：校验逻辑完全运行在用户的浏览器上，攻击者可以完全控制这个执行环境。当你仅仅在文件系统中将 shell.php 重命名为 shell.jpg 时，你欺骗了操作系统的文件管理器，但当你通过网页表单选择这个“伪装的jpg”文件时，JavaScript获取到的文件名依然是 shell.jpg ，校验通过。然而，文件内容仍然是PHP代码，服务器如果仅凭后缀名就决定执行方式，那么你的WebShell就上传成功了。但现实是，服务器端往往有更严格的校验，所以“只改后缀”在遇到双端校验时就会失效。

3.2 Burp Suite实战：禁用JS与拦截修改

第一种绕过姿势，就是直接针对这层脆弱的客户端防御。 方法A：禁用浏览器JavaScript。 这是最简单粗暴的方法。在Chrome开发者工具的 Settings （或通过F1打开）中，找到 Debugger 下的 Disable JavaScript 选项并勾选。然后刷新上传页面，再次尝试上传 shell.asp 文件。你会发现，之前烦人的弹窗消失了，表单被顺利提交。此时，立即切换到Burp Suite的 Proxy -> HTTP history 标签页，找到刚才那条POST请求。右键发送到 Repeater 模块进行进一步分析。在 Repeater 中，你可以看到完整的请求报文。如果服务器端没有其他校验，这个请求可能已经成功了。但通常，我们需要进行下一步。

方法B：利用Burp Suite拦截并修改请求。 这是更常