根据Blackhat 2013上发表的一篇论文，仅在其自己的子域（例如secure.host.com）中实现 Double-Submit Cookie 是不够的。您确实必须控制所有子域：

2.1.1 天真的双重提交

双重提交 cookie CSRF 缓解措施很常见，并且实现可能会有很大差异。该解决方案很有吸引力，因为它具有可扩展性且易于实施。最常见的变体之一是天真：

if (cookievalue != postvalue) 
 throw CSRFCheckError 

使用天真的双重提交，如果攻击者可以写入 cookie，他们显然可以破坏保护。再说一次，写 cookie 比阅读它们要容易得多。

Cookie 是可以写的，这对很多人来说是很难理解的。毕竟，同源策略不是规定一个域不能访问另一个域的cookie吗？但是，有两种常见情况可以跨域编写 cookie：

1. 虽然 hellokitty.marketing.example.com 确实因为同源策略而无法读取 cookie 或从 secure.example.com 访问 DOM，但 hellokitty.marketing.example.com 可以将 cookie 写入父域（example.com） ，然后这些 cookie 会被 secure.example.com 使用（secure.example.com 没有很好的方法来区分哪个站点设置了 cookie）。

此外，还有一些方法可以强制 secure.example.com 始终首先接受您的 cookie。这意味着 hellokitty.marketing.example.com 中的 XSS 能够覆盖 secure.example.com 中的 cookie。

其次，这种方法容易受到中间人攻击：

2. 如果攻击者在中间，他们通常可以通过 HTTP 强制向同一域发出请求。如果应用程序托管在https://secure.example.com，即使 cookie 设置了安全标志，中间的人也可以强制连接到http://secure.example.com并设置（覆盖）任何任意 cookie（即使安全标志阻止攻击者读取这些 cookie）。

即使在服务器上设置了 HSTS 标头并且访问该站点的浏览器支持 HSTS（这将阻止中间人强制执行纯文本 HTTP 请求），除非 HSTS 标头以包含所有子域的方式设置，否则一个人在中间可以简单地强制一个单独的子域请求并覆盖类似于 1 的 cookie。换句话说，只要http://hellokitty.marketing.example.com不强制 https，那么攻击者可以覆盖任何example.com 子域。

总之：

1. 您必须控制所有子域。
2. 您必须设置该Secure标志以确保仅通过 HTTPS 发送 cookie。
3. 如果您关心中间人攻击，则必须将整个网站转换为 HTTPS，设置HSTS标头并确保它包含所有子域。目前，只有 58% 的浏览器支持 HSTS（Internet Explorer 是一个明显的例外）。预计这将在未来一年发生变化。

有关生成值所需的令牌长度和 RNG 类型的讨论，请参阅https://security.stackexchange.com/a/61041/5002。

尽管所有 XSS 攻击都胜过 CSRF 保护，但这些攻击需要与攻击者不同的努力。攻击者很容易通过 XSS 攻击获得诸如令牌之类的简单保护，因为他们可以简单地从 DOM 中读取令牌值并在任何后续表单提交中使用它。需要密码或 OTP 重新身份验证的敏感表单更容易受到攻击，因为他们需要设计攻击以以某种方式捕获用户凭据或 OTP。然而，通过对 DOM 的完全控制，他们可以模仿登录页面来欺骗用户认为他们已经注销并等待用户输入他们的凭据......在这种情况下，他们可能会直接以受害者身份登录而不是只执行 CSRF 攻击。这种攻击还会对网站造成明显的破坏，

对于子域，双重提交 cookie 存在两个风险。子域上的攻击者读取 cookie 值。例如，如果在级别上设置了非主机专用 cookieexample.com ，则控制的攻击者foo.example.com将能够读取 cookie 值。设置仅限主机的 cookie 可以抵抗这种攻击。

攻击者编写 cookie 的另一个风险。与 DOM 的其他部分相比，cookie的同源策略更加宽松。这意味着攻击者控制可以设置一个 cookie，当受害者访问或foo.example.com时将读取该 cookie 。他们只是在级别上设置了一个非主机。即使受到攻击的站点，例如通过 HTTPS 设置仅主机 cookie，并设置安全标志以防止其通过纯 HTTP 泄漏，攻击者自己设置纯 HTTP cookie 仍然能够设置要读取的 cookie 。原因是服务器不能告诉设置它的实际域，也不能查询安全标志本身。example.combar.example.comexample.combar.example.combar.example.com

双重提交 cookie 也容易受到中间人攻击者的攻击，该攻击者可以拦截和更改除 HTTPS 流量之外的所有内容。即使目标站点example.com不侦听纯 http（即端口 443 仅对 TLS 开放），攻击者也可以使用 HTTP 3xx重定向任何http://example.com纯 http 请求（例如 to ），然后拦截该请求，发回带有为example.com. 服务器将采用该值，因为它无法确定它不是带有安全标志的 cookie。这又是由于 cookie 的同源政策宽松。

所有这一切的解决方案是实施HTTP 严格传输安全并控制所有子域。在受支持的浏览器中，这将完全阻止浏览器在 HSTS 记录的生命周期（可能是几年）内建立任何普通的 http 连接，并保护 cookie 不被攻击者设置。HSTS 条目也可以提交给浏览器供应商以包含在构建中，这意味着用户不必访问该站点至少一次即可设置 HSTS 记录。请参阅HSTS 预加载。