攻击利用了哪个习惯？
浏览器可能自动附带目标站点的登录 Cookie。若服务端只检查有无登录状态，外部页面诱发的请求也可能执行状态变更。[1]
016 / Web 与应用 / CSRF
带着登录凭据，就代表本人同意？
CSRF · CSRF
浏览器会按规则附带 Cookie，但这不等于用户有意发起了操作。沿着请求来源、Cookie 条件和服务端校验，一层层检查是否该改变状态。
开始探索 ↓7–10 分钟
动手实验 · 场景判断 · 实用检查
动手实验 · 场景判断 · 实用检查
浏览器角色带着信封去办理操作，背后却有外部页面牵线。重点是请求来源与意图，不能把“携带凭据”当作充分授权。
展开读图提示
读图提示
- 角色与机制
- 礼物网页比喻诱导页面，浏览器角色比喻自动携带登录凭据发请求的用户浏览器。
- 风险在哪里
- 服务端若仅凭随请求附带的 Cookie 信任一次敏感操作，就可能把攻击者诱发的请求当成用户本意。
- 防护与边界
- 对状态变更请求校验 CSRF 令牌并检查请求来源，结合合适的 SameSite Cookie；关键操作再核实用户意图。
本课任务 / CSRF
把“已登录”与“这次操作确实来自受信任流程”分开验证。
- 观察 SameSite 与请求上下文
- 比较 CSRF 令牌和来源检查
- 辨别同站、同源与读取响应
亲手探索 / 不同条件，不同结果
逐步推演：请求发出后，服务端会改变状态吗？
改变跨站或兄弟子域、请求方式、明确设置的 SameSite 以及服务端防护。练习把 Cookie 发送和业务执行分开判断，不发出真实请求。
会话借用实验
浏览器带了通行证，等于你同意了吗？
小珊已登录账户网站。另一页面试图把「接收每周通知」改为「关闭」。先看 Cookie 会不会跟上，再看服务端会不会接受操作。
尚未运行。先观察请求和服务端条件，再运行这次本地演示。
试一试：Lax + 顶层 GET 时，先保留错误接口，再启用「只接受 POST」。随后换成 Strict + 同站子域，观察令牌与精确来源校验各自能拦在哪里。
纯本地规则演示，不发送真实请求、执行 HTML 或保存设置；不模拟完整浏览器、重定向、复杂祖先链或 XSS。
随手查 / 把理解带回实际工作
理解机制之后，检查这些细节。
实验是简化模型。真实环境需要明确业务规则、验证失败路径，并持续维护配置与证据。
01 / 实用细节
状态变更不能寄托在 GET 上
GET 应用于安全的读取语义。顶层导航的跨站 GET 在某些 SameSite 策略下仍可带凭据；把敏感操作放在 GET，会破坏对请求方式的安全预期。[1][3]
02 / 实用细节
令牌在服务端验证
使用框架成熟的 CSRF 方案，将令牌与会话或请求流程正确关联。服务端必须检查缺失和错误值，不能只在页面放一个字段而不校验。[1]
03 / 实用细节
来源检查要有明确预期
核对 Origin 或按方案处理 Referer 时，准确匹配允许来源并定义缺失情况。反向代理后的目标来源需要可信配置，不能盲目信任外部传来的主机信息。[1]
04 / 实用细节
SameSite 提供额外限制
显式选择适合业务的 Strict、Lax 或 None；None 通常需要 Secure。浏览器隐私设置、请求方式和上下文会影响发送结果，本页模型不覆盖所有实现差异。[2]
05 / 实用细节
同站兄弟子域也是边界
一个不可信的兄弟子域可能与业务站点同站。仅依赖 SameSite 不会自动赋予精确来源信任；会话范围、子域管理与服务端校验需要配合。[1][2]
06 / 实用细节
别忘了 XSS 与敏感操作复核
站内脚本执行可能破坏许多 CSRF 防护假设。高风险操作还应按业务要求确认意图或重新认证，同时治理 XSS，避免把一层控制当成万能保障。[1]
从模拟，到验证
找一个获准的环境，实际检查一次。
勾选用于本页自查，不会自动标记整课已学会。练习与清单刷新后重置。
本页已检查 0 / 5 项
Cookie 登录的转账接口该增加哪种校验？
能解释原因，再标记学会。
小测结果同步错题本；“已学会”沿用原有本地学习记录。
资料与依据
- OWASP · CSRF Prevention ↗
令牌、来源验证与纵深防御
- IETF RFC 9110 · Safe Methods ↗
安全方法与 GET 的语义
本页场景、人物与数据均为教学示例。互动选择不会上传；收藏、已学会与错题沿用当前浏览器本地存储。来源正文核对日期：2026-10-08。