# CSRF 跨站请求伪造：借刀杀人之术｜红蓝对抗视角 > 一句话核心：**利用用户当前浏览器的登录态，诱导用户在已登录状态下，无意识发起非预期请求，在目标网站执行操作；攻击者拿不到Cookie，只是借用浏览器自带的身份。** > 类比（借刀杀人）：你已经登录了银行网站，攻击者给你一张图片，你点开一瞬间，浏览器自动带着你的银行Cookie提交转账请求；网站分不清这个请求是用户主动操作还是被诱导触发。 ## 一、原理拆解 1. 用户A登录业务网站`xxx.com`，浏览器保存登录Cookie（会话凭证）。 2. Cookie特性：**访问xxx.com时，浏览器自动带上对应域名Cookie**。 3. 攻击者构造恶意页面，嵌入自动提交的表单/图片/JS。 4. 用户A访问恶意页面 → 浏览器自动发起对`xxx.com`的请求，**自动带上A的Cookie**。 5. 服务端收到请求，校验Cookie有效，认为是用户本人操作，执行请求对应的业务动作。 > ✅关键区分（演练高频考点） > - CSRF：**不能读取返回内容，只能发起请求**；拿不到Cookie、拿不到页面数据，只能执行操作（改密码、添加管理员、下单） > - XSS跨站脚本：可以读取Cookie、读取页面内容，权限更强。 > 一句话：XSS是偷你的凭证；CSRF是借用你已有的登录身份发请求。 ## 二、利用条件（缺一不可） 1. 目标网站**仅依靠Cookie做身份认证**，没有额外校验手段。 2. 存在可执行动作的接口（修改密码、新增账号、后台配置、转账）。 3. 接口操作**仅用GET/POST参数执行，没有CSRF Token、验证码、二次确认**。 4. 受害者处于**已登录状态**，且访问攻击者构造的恶意页面。 ## 三、常见Payload形式 ### 1. GET型CSRF（最简单，图片标签触发） ```html ``` 用户打开包含这行代码的网页，浏览器自动请求这个地址，携带Cookie。 ### 2. POST型CSRF（自动提交表单） ```html
``` 页面加载自动提交POST表单。 > 限制：不能跨域读取接口响应结果，只能发送请求。 ## 四、攻击链路 1. 红队寻找业务接口：后台增删改接口，测试是否存在CSRF 2. 验证：接口是否只依赖Cookie，无token校验 3. 构造恶意HTML页面（攻击载体） 4. 诱导已登录管理员访问页面（邮件、聊天消息） 5. 浏览器自动发起请求，服务端执行操作（新增管理员、修改配置） 6. 完成攻击，全程攻击者无法获取Cookie，仅借用用户会话 ## 五、蓝队检测与识别 ### 审计方法 抓包观察关键业务请求： - 请求头是否携带`X-CSRF-Token`、`anti-csrf-token`等随机令牌 - 敏感操作是否有验证码、二次弹窗确认 - 校验请求来源：`Referer`、`Origin`头 ### 日志特征 - 正常业务：敏感操作请求来源是本站页面 - CSRF攻击：请求Origin/Referer为外部恶意网站域名 > 注意：部分浏览器支持**剥离Referer头**，仅靠Referer防护不牢靠。 ## 六、防御方案（优先级从高到低） 1. **CSRF Token（最标准方案）** 敏感接口每次请求附带服务端生成的随机token，放在表单/请求头，和session绑定；攻击者无法获取这个随机值，无法构造请求。 2. **校验Origin / Referer请求头** 校验请求来源域名，拒绝外部域发起的请求；作为辅助手段，不可单独依赖。 3. **敏感操作增加二次验证** 验证码、短信验证、弹窗确认。 4. **Cookie设置 SameSite 属性（现代浏览器防御）** `SameSite=Strict` / `Lax`，限制跨站场景下自动携带Cookie。 ``` Set-Cookie: JSESSIONID=xxxx; SameSite=Lax; HttpOnly ``` > SameSite是浏览器层面防护，老浏览器不支持，不能替代Token。 ## 七、实战踩坑 1. HttpOnly Cookie **不防CSRF**！HttpOnly是防止XSS读取Cookie，CSRF不需要读取Cookie，浏览器自动携带。（极易混淆的坑！） 2. 很多人误以为POST不能CSRF，POST型CSRF非常常见，只是需要自动提交表单。 3. CSRF无法拿到返回数据，**不能直接读取页面内容**，只能执行操作；想拿数据需要搭配其他漏洞。 ## 一句话速记 CSRF = 借用户浏览器已登录的Cookie自动发起跨站请求；**只执行操作，无法窃取Cookie和页面数据；核心防御是CSRF Token**。 --- 下一章：**XSS跨站脚本：前端代码注入，窃取会话与钓鱼**，继续吗？