浏览器发送 Cookie？
—正在计算发送规则。
WEB 认证 · 会话攻防实验台
一张 Cookie，究竟在哪一关被拦住？
攻击能否成功，不取决于“安全选项开了几个”，而取决于请求沿途经过的每一道判断。选择一个攻击，再改变现场条件。
当前实验
CSRF：浏览器太“听话”
攻击者不知道会话标识，只诱导已经登录的浏览器向目标站提交转账 POST。
攻击被阻断
脚本读取 Cookie？
—正在计算脚本访问边界。
服务器接受请求？
—正在计算服务端校验结果。
攻击最终成功？
—正在计算攻击结果。
这一关真正验证了什么
CSRF 防线要证明状态变更来自目标站内生成、并与当前会话绑定的请求，而不只是证明浏览器已经登录。
Cookie 自动携带 + 缺少请求意图校验 → CSRF 风险
防线边界
当前攻击下，哪些控件真的相关？
绿色表示这项配置正在切断本攻击链；红色表示它留下了缺口；橙色表示它很重要，但并不直接解决当前这条路径。
HTTPS + Secure
保护传输并限制 Cookie 在明文连接中发送，但不判断一个 HTTPS 请求是否出自攻击者意图。
HttpOnly
阻止脚本直接读取会话 Cookie；XSS 仍可能在页面内借浏览器发起已登录操作。
SameSite
限制浏览器在跨站上下文中携带 Cookie；Lax 对顶层、安全方法导航仍有例外。
CSRF 令牌
验证状态变更请求是否携带与当前会话绑定的不可预测值；它不是 XSS 修复工具。
登录后轮换
让登录前已知的旧 SID 作废，专门切断会话固定；不能自动追回后来被偷走的新 SID。
服务端撤销
让已泄露的 Bearer 会话在服务端失效；只清浏览器 Cookie 并不能阻止攻击者继续重放。