1个小时CSRF审计实战，搞懂CSRF漏洞！CSRF跨站请求伪造漏洞原理及代码审计

这门课的主题很窄，就是 CSRF（跨站请求伪造）：从浏览器的同源策略与 Cookie 携带规则讲起，落到服务端代码里“哪个环节漏了校验”，最后用审计视角把常见写法逐个过一遍。适合已经能看懂一门后端语言（PHP/Java/Python 任一）、想补上 Web 漏洞审计这块拼图的人。

技术栈与前置知识

CSRF 本身不依赖某种框架，它依赖的是浏览器行为和服务端会话机制。所以这门课真正的技术底座是两块：HTTP 协议里 Cookie 的发送规则（SameSite、Domain、Path、Secure 这些属性到底怎么影响请求是否带凭证），以及服务端会话的识别方式（Session ID 放在 Cookie 还是 URL、是否用 Token 二次校验）。

审计侧需要能读懂请求处理链路：路由分发 → 参数绑定 → 业务逻辑 → 数据落库。任何一环缺少对“请求来源”的确认，都可能成为 CSRF 的入口。如果你平时写过表单提交、后台管理接口，或者调过 RESTful API，看这门课会顺畅很多；如果完全不熟 HTTP 状态码和 Cookie 头，建议先把这部分补齐再进来。

课程结构：原理 → 利用 → 审计

课程按“先建立模型，再动手复现，最后回到代码”的顺序推进。原理部分讲清楚 CSRF 成立的三要素：受害者已登录、攻击者能构造请求、服务端无法区分请求是否来自本站。这三条缺一不可，审计时也正好对应三个排查方向。

利用环节会演示一个可运行的场景：构造诱导页面，让已登录用户在不知情的情况下发起一次状态变更请求。这里重点不是“怎么攻击”，而是观察请求发出后，服务端究竟收到了什么——Referer 有没有、Cookie 带没带、Token 参没参与校验。把这一步看清，后面的审计才有判断依据。

审计部分是主体。会逐一分析常见防御写法的有效性：Referer 校验在什么情况下会被绕过、Token 放在表单隐藏域和放在请求头有什么区别、双重 Cookie 校验为什么在特定子域场景下会失效、SameSite 属性配置成 Lax 和 Strict 分别拦住了哪些请求。这些都是能在真实代码里直接对照的检查点。

可复用的审计思路

与其记住零散的漏洞特征，不如带走一套可迁移的检查流程：先定位所有会改变服务端状态的接口（新增、修改、删除、转账、改密），再逐个确认这些接口是否校验了请求来源或携带了不可预测的令牌，最后检查令牌是否与会话绑定、是否一次性、是否可被预测。这套流程同样适用于后续分析 SSRF、越权等问题时的入口梳理。

课程里提到的章节笔记适合用来对照复盘。建议看的时候随手打开一个自己熟悉的后台项目，把讲到的检查点挨个套进去，比单纯看视频印象深得多。

自学路径建议

• 先花时间搞懂 Cookie 与同源策略的交互规则，这是理解 CSRF 的前提；
• 跟着课程复现一次完整的请求构造，重点看服务端日志里请求长什么样；
• 拿一个已有的登录态接口做审计练习，判断它是否可被 CSRF；
• 整理一份自己的检查清单，把 Token、Referer、SameSite 三类防御的失效条件写清楚。

这门课只有一小时左右的体量，但它给的是一条能反复使用的审计路径。看完之后真正有价值的事，是拿它去审你自己接触过的代码，而不是停留在“知道 CSRF 是什么”。