问CSRF与X-CSRF-Token的区别

EN

CSRF保护有多种方法。

传统的方式(

“同步器令牌”模式

)通常涉及为每个请求设置唯一的有效令牌值，然后在随后发送请求时验证该唯一值。这通常是通过设置一个隐藏的表单域来完成的。令牌值通常是短暂的，并且与该会话相关联，因此，如果黑客试图重用他们之前在页面上看到的值，或者试图猜测该值，他们很可能会失败。因此，只有来自您的应用程序的请求才能工作，而来自您的应用程序/域之外的伪造请求(也称为跨站点请求伪造)将会失败。

这样做的缺点是需要您的应用程序在所有HTML表单上设置此隐藏标记。这些页面现在必须由应用程序动态生成，而以前它们可能是静态HTML。它还可以中断back按钮(因为您需要刷新表单以重新生成另一个唯一的CSRF值)。您现在还需要跟踪服务器端的有效令牌，并使用有效令牌检查任何请求。这可能需要花费相当多的额外努力来实现和维护。

另一种方法(称为

"Cookie-to-header token“模式

)是为每个会话设置一次Cookie，然后让JavaScript读取该cookie并设置自定义HTTP头(通常称为

或者

或者只是

)。任何请求都将同时发送标头(由Javascript设置)和cookie (由浏览器设置为标准HTTP标头)，然后服务器可以在

标头与cookie标头中的值匹配。其思想是，只有运行在相同域上的JavaScript才能访问cookie，因此来自另一个域的JavaScript不能将此标头设置为正确的值(假设页面不容易受到允许访问此cookie的XSS的攻击)。即使是虚假链接(例如，在网络钓鱼电子邮件中)也不会起作用，因为即使它们看起来来自正确的域，也只会设置cookie，而不是

标题。

这可能比同步器令牌模式更容易实现，因为您不需要为每个表单的每个调用设置令牌，而且检查也相对简单(只需检查cookie与标头匹配)，而不是跟踪CSRF令牌的有效性。您所需要做的就是为每个会话设置一个随机值的cookie。如果一些前端框架看到cookie，它们甚至会自动为您生成标头(例如

AngularJS可以做到这一点

例如)。

缺点是它需要JavaScript才能工作(但如果你的应用程序基本上没有JavaScript就不能工作，这可能不是问题)，而且它只适用于JavaScript发出的请求(例如XHR请求)--常规的HTML form请求不会设置头部。它的一个变体(

“双重提交Cookie”模式

)将

值而不是HTTP标头中的值来解决此问题，但仍然保持服务器端逻辑比传统的同步器令牌模式更简单。然而，应该注意的是，

OWASP指出了双重提交方法的一些缺点

，当攻击者能够设置cookie时(这通常比读取cookie更容易)，因此建议在这种情况下验证CSRF令牌。

此外，Synchronizer令牌模式可以允许额外的控制来强制执行流程(例如，只有当应用程序认为您发送了一个有效的请求来获取表单时，才会设置隐藏字段CSRF令牌)。

哦，一些安全扫描会发现cookie没有设置

标志可以被JavaScript读取-但这是故意的，因为它需要能够读取！错误警报。你可能会认为，只要你使用一个普通的名字，比如

他们知道不要标记它，但经常看到它被标记。

所有这些都是用于跨站点请求伪造保护和

你只需要使用其中的一个

向后端发送请求时。不同的名字来自不同的框架。

这一切都是关于发送一个

到后端。然后，后台会将其与存储在数据库中的特定用户的CSRF值进行比较。

csrf：

用于HTML表单(不是AJAX)

在后端生成，同时呈现HTML表单。

我们不能直接在HTML表单中设置请求头，所以我们必须通过表单输入将其作为

隐藏字段

..。

您可以将此隐藏输入命名为任何您想要的名称。

例如：

X-CSRF-TOKEN:

• It is added to the request HTTP header for AJAX requests.
• To use it, we can put the csrf value in a tag while rendering the HTML, then in front end we can get the value from that tag and send it to backend.

Laravel specific:

• When using Laravel as backend. Laravel checks this header automatically and compares it to the valid csrf value in database (Laravel has a middleware for this).

X-XSRF-TOKEN:

• It is added to the request header for AJAX requests.
• Popular libraries like Angular and Axios, automatically get value of this header from XSRF-TOKEN cookie and put it in every request header.
• To use it, we should create a cookie named XSRF-TOKEN in backend, then our front end framework that uses Angular or Axios will use it automatically.

Laravel specific:

• Because it's popular, Laravel creates this cookie in each response.
• so when you're using for example Axios and Laravel you don't need to do anything, just log user in and 'auth' middleware will do the job.
• It's a bigger string compared to X-CSRF-Token because cookies are encrypted in Laravel.