CSRF（跨站请求伪造）攻击全流程讲解

更新: 5/24/2026 字数: 0 字时长: 0 分钟

一、前置触发条件

CSRF 攻击之所以能够成立，必须同时满足以下三个条件，缺一不可：

用户已登录正规站点：用户在被攻击的正规站点（如银行、社交平台）完成了登录，浏览器中保存了该站点有效的会话凭证（Cookie / Session）。
用户未退出登录：用户没有关闭浏览器或主动登出，会话凭证仍然有效。
用户在同一浏览器中访问了恶意站点：用户在登录态未失效期间，被诱导（如点击钓鱼链接、打开恶意邮件、访问被植入恶意代码的网页）访问了攻击者控制的恶意站点。

此外，正规站点本身存在防护缺陷——仅依赖 Cookie 验证用户身份，而没有校验请求来源（如缺少 CSRF Token、未校验 Referer/Origin），这是攻击得以成功的技术根因。

二、攻击全流程（按时间顺序）

步骤 1：用户正常登录正规站点

用户：在浏览器中打开正规站点（如 bank.com），输入账号密码完成登录。
正规站点：验证身份通过后，向用户浏览器下发一个会话 Cookie（如 sessionId=abc123），用于后续识别用户身份。
恶意站点：暂未介入。

此时浏览器保存了 bank.com 的登录态，后续凡是发往 bank.com 的请求，浏览器都会自动携带这个 Cookie。

步骤 2：用户在未登出状态下访问恶意站点

用户：没有关闭银行页面（或虽关闭但 Cookie 未过期），又在同一浏览器中点开了攻击者投递的钓鱼链接，访问了恶意站点（如 evil.com）。
正规站点：无感知。
恶意站点：成功在用户浏览器中加载了恶意页面。

步骤 3：恶意站点构造伪造请求

用户：在恶意页面中可能只看到一张图片、一个按钮，甚至完全无感（页面看似正常）。
恶意站点：在页面中预先埋入了指向正规站点敏感接口的伪造请求。常见手法包括：
- GET 型：用 <img src="https://bank.com/transfer?to=hacker&amount=10000"> 让浏览器自动发起转账请求。
- POST 型：用一个隐藏的自动提交表单：
  html
```
<form action="https://bank.com/transfer" method="POST">
  <input name="to" value="hacker">
  <input name="amount" value="10000">
</form>
<script>document.forms[0].submit();</script>
```
正规站点：尚未收到请求。

用户：完全不知情，浏览器在后台默默执行了恶意页面中的代码。
恶意站点：触发请求后任务完成，自身不直接与正规站点通信。
浏览器（关键中间人）：根据同源策略，只要请求目标是 bank.com，就会自动附上 bank.com 的 Cookie——它无法区分这个请求究竟是用户本人点击触发的，还是恶意页面伪造的。

步骤 5：正规站点错误地执行了恶意操作

用户：仍然毫不知情。
恶意站点：已经达成攻击目的。
正规站点：收到一个携带合法 Cookie 的请求，校验会话有效后，误认为是用户本人的真实意图，于是执行了转账、改密码、发帖、删除数据等敏感操作。

步骤 6：攻击完成，用户事后才察觉

用户：可能在收到短信通知、查看账单或登录后台时才发现异常。
正规站点：从日志看来一切"合规"——请求来自已登录用户、Cookie 有效、参数完整，难以事后追责。
恶意站点：攻击者已获得收益（资金、权限、数据等）。

三、攻击本质一句话总结

CSRF 的核心是：攻击者"借"用户已登录的身份，让用户的浏览器在不知情的情况下，替自己向正规站点发出一个看起来完全合法的请求。

攻击者自始至终拿不到用户的 Cookie，但他能"驱使"浏览器代为操作——这就是"跨站请求伪造"中"伪造"二字的真正含义。