“ X-Requested-By：随便”
，服务器检查“ X-Requested-By”的存在，如果标头不是，则丢弃请求找不到。标头的值无关紧要。这是Jersey 1.9的CsrfProtectionFilter的工作方式，此博客文章中对此进行了描述：http://blog.alutam.com/2011/09/14/jersey-and-cross-site-request-forgery-csrf/。该博客文章还链接到NSA和Stanford的论文，这些文章指出自定义标头本身是足够的保护：
第一种方法涉及为每个REST请求设置自定义标头
，例如X -XSRF标头。此标头的值无关紧要；
简单的存在应该可以防止CSRF攻击。如果请求进入
而没有自定义标头的REST端点，则该请求
应该被删除。
来自Web浏览器的通过表单，图像，iframe，
等执行的HTTP请求无法设置自定义HTTP标头。从具有自定义HTTP标头的浏览器创建
HTTP请求的唯一方法是使用
技术，例如Javascript XMLHttpRequest或Flash。这些
技术可以设置自定义HTTP标头，但是内置有安全策略
，除非策略特别允许，否则可以防止网站向彼此发送请求。这意味着网站
www.bad.com不能使用
自定义标头X-XSRFHeader向http://bank.example.com发送请求，除非他们使用诸如
XMLHttpRequest。除非bank.example.com域明确允许
，否则该技术将阻止发出这样的请求。然后，这将导致只能通过
XMLHttpRequest（或类似技术）调用的REST端点。
重要的是要注意，此方法还可以防止任何直接
从Web浏览器访问该REST端点。使用这种方法的Web应用程序将需要通过XMLHttpRequest或类似技术与REST端点进行接口。
来源：实现REST的准则
但是，似乎大多数其他方法都建议您应该生成令牌并在服务器上对其进行验证。这是工程过度吗？什么时候“存在”方法是安全的？何时还需要令牌验证？
#1 楼
安全是关于深度防御。目前仅检查价值就足够了，但是将来的技术和攻击可能会被利用来破坏您的保护。测试令牌的存在可以实现应对当前攻击所必需的绝对最低限度的防御。添加随机令牌可提高针对未来潜在攻击媒介的安全性。使用每个请求令牌还有助于限制XSS漏洞造成的损害，因为攻击者需要一种方法来针对他们提出的每个请求都窃取新令牌。这与现代的推理相同加密算法，其中
n个回合被认为是安全性的最小值，但是在官方实现中选择了2n+1个回合（例如）以确保体面的安全裕度。进一步阅读：
带有JSON POST的CSRF
为什么要为每个表单请求刷新CSRF令牌？
评论
我不确定您未来的攻击是什么意思，因为链接中提到的enctype不适用于OP的额外标头。您能详细说明一下吗？另外，您提到了限制XSS漏洞的方法，但我认为CSRF令牌不能对此提供帮助。如果恶意XSS脚本可以发送请求，则他们肯定可以读取每个响应的CSRF令牌。我想念什么？
–克里斯·H。
2014年5月20日0:28
@ChrisH。未来的技术和对其站点的更改可能会使攻击者添加标头。如果我没记错的话，HTML5的网络套接字现在允许这样做。更改他的网站可能还会引入HTTP响应拆分错误，也可能会绕过标头检查。关于XSS注释，我指的是以下事实：如果您在A页上有XSS，则具有动态令牌会要求攻击者读取B页，这可能会基于X-Requested-With阻止请求，或者通过CSP进行过滤。
–多项式
2014年5月24日，0：24
我找不到任何证明可以使用Web套接字来规避此保护的证据，也不清楚您所说的“ HTTP响应拆分错误”的含义。你能详细说明一下吗？
–吉利
2014年6月5日在3:03
@Gili他们不能这样做；我错了。也就是说，绝对可以使用Ajax欺骗X-Requested-With标头，尽管当然CORS策略仍然适用。 Rook在下面的响应展示了一个漏洞示例；其他可能也存在（例如，XMLHttpRequest中的CORS旁路仅适用于JSON数据）。
–多项式
16年7月11日在16:44
这是近期的一种攻击，它绕过了用作CSRF保护的静态标头：insert-script.blogspot.cz/2018/05/…当然，此特定攻击仅适用于IE用户的一个子集。尽管如此，它仍说明了为什么静态标头不是可靠的CSRF保护机制。
–巴约
18年5月4日在9:59
#2 楼
TL; DR-检查是否存在诸如“ X-Requested-By”之类的非标准标头足以抵御CSRF攻击，而无需检查标头的值。非标准标头不能被设置为CSRF攻击
Play框架站点可以很好地将其分解：
简而言之，攻击者可以强迫受害者的浏览器进行以下操作：请求类型：
所有GET请求
正文类型为application / x-www-form-urlencoded，multipart / form-data和text / plain的POST请求
/>
攻击者不能：
强制浏览器使用其他请求方法，例如PUT和DELETE
强制浏览器发布其他内容类型，例如作为application / json
强制浏览器发送新的cookie（服务器已设置的cookie除外）
强制浏览器设置任意标头，而不是浏览器添加到请求中的普通标头
Thi如果考虑CSRF的攻击媒介，则s是有意义的：
GET请求（例如
评论
如果CSRF攻击是由注入的脚本（例如，通过存储的XSS）生成的，该怎么办。如果我没有记错的话，这种方法将无法保护这项技术。XSS始终会覆盖CSRF-如果您容易受到CSRF的攻击，那么任何CSRF保护都将受到破坏。
stackoverflow.com/questions/3315914/…
如果服务器的CORS策略较弱（null *和缓存错误），则跨源javascript请求可能由浏览器触发；自定义标头总比没有好，但不是最安全的方法