关于Double Submit Cookie机制：攻击者能否提前获取表单令牌？

你的理解存在部分偏差，Double Submit Cookie能防CSRF的核心是依赖浏览器的同源策略和Cookie的作用机制，攻击者根本无法拿到能匹配用户当前Cookie的有效token，下面拆解你的疑问：

为什么攻击者的步骤不成立？ #

你的攻击流程里，第3步和第4步存在致命漏洞：

1. 同源策略限制读取Cookie：当attacker.com通过用户浏览器向vulnerable.com发GET请求时，vulnerable.com确实会在用户浏览器的Cookie中设置新的token，同时返回带token的表单，但attacker.com的JS代码完全无法读取这个Cookie——浏览器的同源策略明确规定，非同源的网站不能访问其他域名下的Cookie。
2. token与Cookie的绑定关系不匹配：就算攻击者拿到了表单里的token，他构造的恶意表单提交请求时，浏览器会自动带上用户当前vulnerable.com的Cookie（可能是用户之前正常访问时留下的，或者这次GET请求新设置的），但这里有两个关键问题：
   • 如果服务端设置了Cookie的SameSite属性（比如SameSite=Lax或SameSite=Strict），跨域发起的GET请求不会带上vulnerable.com的原有Cookie，服务端生成的新token对应的Cookie是临时的，但攻击者构造的表单提交属于跨域POST请求，同样不会带上这个临时Cookie，导致token和Cookie不匹配。
   • 就算没有SameSite属性，攻击者拿到的表单token是和这次GET请求生成的Cookie绑定的，但攻击者无法在构造的表单里强制浏览器使用这个Cookie——浏览器会自动带上用户当前vulnerable.com的Cookie，而这个Cookie里的token和攻击者拿到的表单token大概率不一致（除非用户刚好在这次GET请求后没有其他操作，但攻击者无法控制这一点）。

你对Double Submit Cookie的理解偏差 #

Double Submit Cookie的正确实现有两种常见方式：

• 服务端同时下发Cookie和表单token：服务端生成token后，既设置到Cookie，又在表单的隐藏字段中输出相同的token，提交时校验两者是否一致。
• 客户端从Cookie中提取token填充表单：服务端只设置token到Cookie（非HttpOnly），客户端通过JS读取Cookie中的token，自动填充到表单的隐藏字段中，提交时服务端校验表单token和Cookie是否一致。

两种方式的核心都是：攻击者无法跨域获取用户的Cookie，也就无法拿到能匹配的token，而跨域请求时浏览器会自动带上Cookie，但攻击者无法构造出带相同token的表单。

额外的实现细节保障 #

很多站点还会配合以下策略强化防护：

• 检查请求的Origin或Referer头，拒绝跨域的表单获取或提交请求。
• 设置Cookie的Secure属性，确保Cookie只在HTTPS连接下传输。
• 每个会话或每个请求生成唯一的token，避免token被复用。

内容的提问来源于stack exchange，提问作者BaconErie