CSRF和X-CSRF-Token之间的区别

Question

隐藏字段中标题或标记中使用X-CSRF-Token有什么区别？

使用隐藏字段时和使用标题时为什么？

我认为X-CSRF-Token是我使用javascript / ajax但我不确定

Answer 1

CSRF保护有多种方法。

传统方式（＆＃34;同步器令牌＆＃34;模式）通常涉及为每个请求设置唯一的有效令牌值，然后在随后发送请求时验证该唯一值。通常通过设置完成隐藏的表单字段。令牌值通常是短暂的并且与该会话相关联，因此如果黑客尝试重用他们之前在页面上看到的值，或者尝试猜测它们可能会失败的值。因此，只有来自您的应用程序的请求才会起作用，并且来自您的应用程序/域外的伪造请求（也称为跨站点请求伪造）将失败。

缺点是它需要您的应用程序在所有HTML表单上设置此隐藏令牌。这些页面现在必须由应用程序动态生成，之前可能是静态HTML。您现在还需要跟踪服务器端的有效令牌，并检查使用有效令牌的任何请求。这可能需要花费很多额外的精力来实施和维护。

另一种方法是每个会话设置一次Cookie，并让JavaScript读取该cookie并使用该值设置自定义HTTP标头（通常称为X-CSRF-TOKEN）。任何请求都将发送标头（由Javascript设置）和cookie（由浏览器设置为标准HTTP标头），然后服务器可以检查X-CSRF-TOKEN标头中的值是否与cookie标头中的值匹配。这个想法是只有在同一个域上运行的JavaScript才能访问cookie，因此来自另一个域的JavaScript无法将此标头设置为正确的值（假设该页面不容易受到允许访问此页面的XSS的攻击曲奇饼）。即使虚假链接（例如在网络钓鱼邮件中）也不会起作用，因为即使它们看起来来自正确的域，也只会设置cookie但不会设置X-CSRF-TOKEN标题。

这可以比＆＃34; Synchronizer令牌更容易实现＆＃34;模式，因为您不需要为每个表单的每次调用设置令牌，并且检查也相对简单（只检查cookie与标题匹配），而不是跟踪CSRF令牌的有效性。您只需要为每个会话将cookie设置为随机值。

缺点是它需要JavaScript才能工作（但如果你的应用程序在没有JavaScript的情况下基本上无法工作，这可能不是问题）并且它只适用于JavaScript发出的请求（例如XHR请求） - 常规HTML表单请求不会设置标头。此外，Synchronizer令牌模式可以允许额外的控件来强制执行流程（例如，只有当应用程序认为您已发送有效请求以获取该表单时，才会设置隐藏字段CSRF令牌。）

哦，一些安全扫描会发现cookie没有使用HTTP-ONLY标志设置，所以可以通过JavaScript读取 - 但这是故意的，因为它需要能够读取！虚警。你想，只要你使用像X-CSRF-TOKEN这样的通用名称，他们就会知道不会标记这一点，但是经常看到它被标记。

Answer 2

所有这些都是用于跨站点请求伪造保护的，并且在向后端发送请求时，您只需使用其中一个。

csrf：

• 以html形式使用（不是ajax）
• 我们无法在html表单中设置请求标头，因此我们必须通过表单输入将其发送为隐藏字段。

x-csrf令牌：

• 它被添加到ajax请求的请求标头中。
• 使用laravel作为后端时。 laravel自动检查此标头，并将其与数据库中有效的csrf进行比较。

x-xsrf令牌：

• 它被添加到ajax请求的请求标头中。
• 受欢迎的库（例如angular和axios）会自动从xsrf-token cookie中获取此标头的值，并在每次请求时将其发送。
• 因为它很流行，所以laravel在每个响应中都创建了这个cookie。
• 因此，例如在使用axios和laravel时，您无需执行任何操作。只需登录用户，“ auth”中间件就可以完成工作。
• 与x-csrf-token相比，它的字符串更大，因为cookie是在laravel中加密的。