假设我们在表单中使用了CSRF令牌，但我们网站上发现了一个未被注意的XSS漏洞。
根据我的理解，在这种情况下，CSRF令牌保护完全无效，因为攻击者可以通过XSS使用XMLHttpRequest来检索它。
在这种情况下，是否有办法以一种能够在攻击中幸存下来的方式来附魔CSRF保护，或者在做任何CSRF之王之前我们的网站是否应首先拥有安全的抗XSS保护？
在每次页面请求时设置一个新令牌而不是登录时的令牌会处理它吗？这带来了一次打开更多表格的问题，我不喜欢它。
答案 0 :(得分：3)
您的网站应该关闭您发现的任何XSS漏洞，否则CSRF无用。但是，并行添加CSRF会很有用，这样一旦修复了所有XSS错误，站点的csrf保护也会起作用。
不幸的是，如果存在XSS漏洞，则无法防范CSRF，因为有了XSS漏洞，攻击者可以读取您的网站并检查令牌（使用javascript）。因此，无论何时何地添加令牌，都可以找到该令牌，然后进行屏幕划分
但是，如果您确保重要页面上没有XSS错误然后添加CSRF保护，那么仍然存在安全漏洞，但将多个错误链接在一起所需的技能水平更加困难。
答案 1 :(得分：1)
简答： Origin header check是唯一的 csrf 保护机制，即使存在XSS漏洞，它也能保持良好状态。
这些是我们用来阻止CSRF的技术
使用Synchronizer Token方法，服务器在输入表单中嵌入一个动态隐藏变量（请密切注意，服务器必须对表单生成具有绝对控制权，以便它可以生成随机字符串并嵌入表单中）和将它保存在服务器端的会话中 - ＆gt;在表单上验证提交并在会话使用一次后立即使其无效。这不适用于为完全独立的SPA（单页面应用程序）供电的Restful服务，因为微服务无法访问SPA＆＃39;形式生成机制。提交表单时，服务器可以检查并确保隐藏变量存在并且它是正确的值。看，这是在正文中发送的（如果我们将这个新令牌设置为cookie而不是表单体，它会使整个事情失败，这与sessionID之间没有区别）。
如果mybank.com没有清理表单输入（或换句话说，如果mybank.com易受xss攻击）黑客can overcome这种csrf预防方法。 https://rileykidd.com/2013/09/09/using-xss-to-csrf/
使用Double Submit Cookie方法，将两个cookie发送回浏览器。一个是会话ID，另一个是随机值（类似于同步器令牌）让我们说sessionid和csrfid就是那些cookie。
有两件事可以使这种机制发挥作用。
1）浏览器中内置的一个名为Same Origin Policy的功能。这允许脚本代码仅在这些端点具有与传递所述脚本代码的端点相同的源（基URI）时才与其他服务器端点交互。你可能想知道，“哇！如果一个cookie本身不安全，那么两个cookie将如何更加安全？“坚持下去，关键是下一点
2）将第二个Cookie（csrfid）包含在自定义标头中的后续请求中（例如，X-XSRF-Token）。由客户端脚本代码决定是否正确设置。
当您请求登录页面时，服务器会发回两个cookie。第二个cookie用于自定义标头，用于来自浏览器的后续请求。服务器检查是否存在自定义标头，并根据为该页面发送的内容检查该值。
与Synchronizer Token方法类似，尝试欺骗页面并诱使您向活动会话提交数据的外部站点将会失败，因为它无法为不同URL的站点设置自定义标头。
服务器必须生成随机值csrftoken cookie，并在会话建立后将其发送到浏览器。
客户需要访问Cookie并为每个后续请求设置自定义标头
服务器需要验证CUSTOM HEADER（只需忽略csrfid（或者你给的任何名字）cookie。因为它是一个cookie，所以无论如何它都会在那里，只是忽略它）
此技术很有效，因为所有浏览器都实现相同的原始策略。只有设置了Cookie的网站上的代码才能从该网站读取Cookie，并在对该网站的请求中设置自定义标头。
打开问题（没有机会对此进行测试）：第二个（csrf-token）Cookie上的httpOnly怎么样？我们需要设置它吗？不？ ..如果我们设置它，Javascript是否能够访问它以设置每个后续请求。另一方面，如果Javascript能够访问它，那么与未消毒形式疏忽的XSS漏洞一起，XSS攻击可以暴露用户的csrf-token。然后，如果邪恶的家伙能够在mybank.com上进行活跃会话时欺骗用户访问evil-site-which-has-a-csrf-form.com，则可以进行csrf攻击。同意，攻击发生的次数太多了 ，但它仍然不是安全。
到目前为止，如果存在XSS漏洞，这些方法效果不佳。我们来看看第3个选项
所有浏览器（包括Internet Explorer 9及更高版本）都会在其请求中发送Origin标头。 Javascript不允许设置此标头，这使您可以高度确信浏览器在该标头中具有正确的信息。然后，服务器可以显式检查该标头并验证基URI是否与服务器匹配。如果服务器设置为拒绝原始标头中的基URI与预期值不匹配的浏览器请求，那么试图欺骗页面外观的第三方网站将被挫败，因为浏览器中设置的Origin将是与预期的不同。
即使mybank.com存在XSS漏洞，这也不会失败。 抓住 Nada！如果您的用户使用（非常）旧版本的浏览器，您可能还有其他问题需要解决：）
参考： https://stormpath.com/blog/secure-single-page-app-problem