跨站请求伪造（CSRF）

CSRF

原理

CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种常见的 Web 安全漏洞，攻击者通过诱导用户在已认证的 Web 应用中执行非预期操作，从而利用用户的身份权限完成恶意行为。
Web 应用通常通过 Cookie（或其他身份凭证）验证用户身份，而浏览器有一个特性：当向某个域名发送请求时，会自动携带该域名对应的 Cookie（即使请求来自其他网站）
CSRF 的核心就是利用这一特性：

1. 受害者先登录目标网站 A，获得有效身份凭证（如 Cookie）
2. 受害者在未退出网站 A 的情况下，访问攻击者控制的恶意网站 B
3. 恶意网站 B 向网站 A 发送一个伪造的请求（如 “转账”“修改密码”）
4. 浏览器自动携带受害者在网站 A 的 Cookie，网站 A 误认为是受害者本人操作，从而执行该请求

CSRF 和 XSS，两者核心差异在于：

• XSS：攻击者通过注入恶意脚本，获取用户的身份凭证（如 Cookie），再冒充用户操作
• CSRF：攻击者不获取凭证，而是直接利用用户已有的有效会话（Cookie 自动携带），诱导用户 “主动” 执行操作

攻击流程

以 “银行转账” 为例，完整攻击步骤如下：

1. 用户登录目标网站：受害者登录网银（bank.com），系统生成 Cookie（sessionid=abc123）并存储在浏览器中，用于后续身份验证

2. 诱导访问恶意网站：攻击者通过邮件、链接等方式，诱导受害者访问恶意网站（evil.com）

3. 发送伪造请求：evil.com的页面中隐藏着一段代码，自动向bank.com发送转账请求

    <!-- evil.com的恶意代码 -->
    <img src="https://bank.com/transfer?to=攻击者账户&amount=10000" style="display:none">
   

4. 目标网站执行操作：bank.com验证 Cookie 有效，认为是受害者主动发起转账，执行转账操作，攻击完成

攻击场景

CSRF 可利用任何 “基于身份凭证即可执行” 的操作，典型场景包括：

• 修改用户信息（如邮箱、密码、收货地址）
• 发起交易（转账、支付、下单）
• 执行权限操作（添加管理员、删除数据、发布内容）

防御

防御 CSRF 的核心是确保请求是用户 “主动且知情” 发起的，常见手段如下：

1. CSRF Token（最有效）

• 原理：
  服务器为每个用户生成一个随机且唯一的 Token（如csrf_token=xyz789），并将 Token 存储在用户会话（Session）中。
• 流程：
  目标网站在生成表单或页面时，将 Token 嵌入表单（隐藏字段）或请求头中；
  用户提交请求时，必须携带该 Token；
  服务器接收请求后，对比请求中的 Token 与 Session 中存储的 Token，一致则认为请求合法，否则拒绝。
• 优势：
  攻击者无法获取用户的 Token（因 Token 与用户会话绑定），因此无法伪造有效请求。

1. 验证 Referer/Origin

• 原理：
  通过 HTTP 头中的Referer（记录请求来源页面的 URL）或Origin（记录请求来源域名），验证请求是否来自可信域名。
• 场景：
  例如银行网站只接受来自bank.com域名的请求，若Referer为evil.com，则拒绝该请求。
• 局限性：
  Referer可能被浏览器或插件屏蔽（如隐私模式）；
  Origin仅包含域名，不包含路径，无法验证子路径合法性。

1. SameSite Cookie 属性

• 原理：
  通过设置 Cookie 的SameSite属性，限制 Cookie 仅在 “同站请求” 中携带（跨站请求不携带）。
  • SameSite=Strict：完全禁止跨站请求携带 Cookie（最严格）
  • SameSite=Lax：允许部分安全的跨站请求（如 GET 表单提交）携带 Cookie（较常用）。
• 优势：
  从源头阻止跨站请求携带 Cookie，无需服务器额外验证。

1. 要求二次验证
   对于敏感操作（如转账、修改密码），强制要求用户输入密码、验证码或短信验证码。攻击者无法绕过二次验证，因此无法执行操作。
2. 限制请求方法
   敏感操作（如修改数据）应使用POST方法，而非GET（GET请求可通过img、link等标签轻易伪造）。
   但需注意：POST也可被伪造（如自动提交的表单），因此不能单独依赖。

实战

靶机pikachu之CSRF（GET）

操作
打开网站可以看到是一个登录界面

点击提示可以看到登录用户名和密码，随机选择一个

尝试修改信息

信息修改成功后可以看到

使用burpsuit进行抓包修改，在提交修改个人信息的时候，可以抓包看到下面的内容
注意：在打开pikachu时使用本机ip而非localhost或127.0.0.1，防止代理过滤

从上面的url可见，修改用户信息的时候，是不带任何不可预测的认证信息的
在登录状态下试试改一改上面的链接，比如把地址改一改
见click.html与requestforgery.html，将地址改为上海

退出后重新登录，可以看到信息修改成功
代码分析

使用session保存的，没有验证码或token

靶机dvwa之CSRF_Low

这是一个修改dvwa登录密码的操作

原有的密码为password，现修改为pass

填写完成后提交，并用burp suite抓包

右键->engagement tools->generate csrf poc
会生成一段html代码，即csrf漏洞测试代码

设置让密码重置为word，而非pass

点击test in browser

copy后再在浏览器打开

因为有burp proxy代理，可以看到访问该url后成功利用用户的登录状态，伪造了重置密码的操作

下次在登录时，输入pass作为密码，看到密码出错

再回到burp，可以看到两次请求的referer完全不同

• 伪造
  

• 真实