Php CSRF令牌和XSS漏洞

假设我们在表单中使用CSRF令牌，但我们的站点上碰巧有一个未被注意到的XSS漏洞

据我所知，在这种情况下，CSRF令牌保护完全无效，因为攻击者可以通过XSS使用XMLHttpRequest检索它

在这种情况下，是否有一种方法可以使CSRF保护在攻击中幸存下来，或者我们的站点在使用任何CSRF之前，是否应该首先拥有一个安全的反XSS保护

---

在每个页面请求上设置一个新的令牌，而不是在登录时设置令牌，可以解决这个问题吗？这就带来了一次打开更多表单的问题，我不喜欢它。

你的站点应该关闭你发现的任何XSS漏洞，否则CSRF是无用的。然而，并行添加CSRF会很有用，这样一旦所有XSS bug都修复了，站点的CSRF保护也能正常工作

不幸的是，如果存在XSS漏洞，就无法防止CSRF，因为攻击者可以通过XSS漏洞读取您的网站并检查令牌（使用javascript）。因此，无论您以何种方式在任何地方添加令牌，都可以找到该令牌，然后进行屏幕抓取

---

但是，如果您确保重要页面上没有XSS错误，然后添加CSRF保护，仍然存在安全漏洞，但将多个漏洞链接在一起所需的技能水平更为困难。

简短回答：

源标题检查

是唯一的csrf保护机制，即使存在XSS漏洞，它也会保持其基础

这些是我们用来防止CSRF的技术

同步器令牌 使用同步器令牌方法，服务器在输入表单中嵌入动态隐藏变量（请密切注意，服务器必须对表单生成具有绝对控制权，以便它可以生成随机字符串并嵌入表单）并将其保留在服务器端的会话中-->在表单提交上进行验证，并在使用一次后立即从会话中将其作废。这不适用于为完全分离的SPA（单页应用程序）供电的Restful服务，因为微服务无法访问SPA的表单生成机制。提交表单时，服务器可以检查并确保隐藏的变量存在并且是正确的值。看，这是在主体中发送的（如果我们将这个新标记设置为cookie而不是表单主体，它会破坏整个过程，它和sessionID之间没有区别）

如果mybank.com没有对表单输入进行消毒（或者换句话说，如果mybank.com易受xss攻击），黑客可以使用此csrf预防方法

双重提交Cookie 使用双提交Cookie方法，两个Cookie被发送回浏览器。一个是会话id，另一个是随机值（类似于同步器令牌），比如说

sessionid

和

csrfid

就是这些cookie

有两件事可以让这个机制发挥作用

1） 浏览器中内置的一项功能，称为

同源策略

。这只允许脚本代码与其他服务器端点交互，前提是这些端点与交付所述脚本代码的端点具有相同的源（基本URI）。你可能会想，“哇！如果一个cookie本身不安全，那么两个cookie怎么会更安全？”等等，关键在下一点

2） 将第二个cookie（

csrfid

）包含在自定义头中的后续请求中（比如，

X-XSRF-Token

）。由您的客户端脚本代码来确保正确设置

当您请求登录页面时，服务器会发回两个cookie。第二个cookie用于来自浏览器的后续请求的自定义标头中。服务器检查是否存在自定义标头，并根据为该页发送的内容检查值

与同步器令牌方法类似，外部站点试图欺骗页面并诱使您向活动会话提交数据将失败，因为它无法在不同的URL上设置站点的自定义标头

主要行动

服务器必须生成一个随机值csrftoken cookie，并在会话建立时将其发送到浏览器

客户端需要访问cookie，并为每个后续请求设置自定义头

服务器需要验证自定义头（只需忽略

csrfid

（或您提供的任何名称）cookie。由于它是一个cookie，因此它将与每个请求一起出现，只需忽略它）

这种技术非常有效，因为所有浏览器都实现相同的源策略。只有设置Cookie的网站上的代码才能读取该网站上的Cookie，并在对该网站的请求上设置自定义标题

开放性问题（还没有机会测试）：第二个（csrf令牌）cookie上的

httpOnly

怎么样。。我们是否需要设置它。。如果我们设置它，Javascript将能够访问它以设置后续的每个请求。另一方面，如果Javascript能够访问它，那么XSS攻击会与未经清理的XSS漏洞一起暴露用户的csrf令牌。然后，如果邪恶的家伙能够欺骗用户访问邪恶的网站-which-has-a-csrf-form.com，同时在mybank.com上有一个活动会话，csrf攻击就会发生。同意，有太多的“if”用于攻击，但仍然不安全

到目前为止，如果存在XSS漏洞，这些方法就没有那么有效。让我们来看一下第三个选项

原点标题检查 所有浏览器，包括Internet Explorer 9和更高版本，都会在其请求中发送

Origin

头。Javascript不允许设置此标题，这使您对浏览器中的信息有高度的信心