上下文：Angular站点托管在CloudFront后面的S3上，与用作API的Express服务器分开，几乎所有请求都是XMLHttpRequests。所有请求均不使用cookie发送（默认情况下，withCredentials = false），我使用JWT Bearer令牌进行身份验证，方法是从角度的cookie中获取它，然后放置到Authorization标头中（这种技术在CSRF Wiki页面中有所描述）。

在Express网站上，我不允许Cookie中的Access-Control-Allow-Headers标头。

Cookie具有secure: true标志，而不具有httpOnly，因为我需要手动访问它们。

我在这篇中型文章中也读到了JSON-Web-Tokens（JWT）/ Bearer Tokens


无疑是最好的方法之一CSRF的问题


问题1：如果我将X-XSRF-Token标头添加到每个请求中，例如通过检查相同的值使该机制变为无状态，是否可以增加安全性在JWT有效载荷？ （我在此线程中了解了它）

问题2：CSRF是否真的需要额外的安全措施才能吸收我描述的所有内容？

#1 楼

这是相关的，但不一定能回答您100％的问题：

https://security.stackexchange.com/a/166798/149676

短小只要验证不是自动的（通常由浏览器提供），那么您就不必担心CSRF保护。如果您的应用程序通过Authorization标头附加凭据，则浏览器将无法自动对请求进行身份验证，并且CSRF也无法实现。因此，我会稍微重述您文章中的引文：承载令牌不是抵御CSRF攻击的最佳方法，而仅仅是CSRF是一种攻击媒介，专门攻击浏览器自动提供身份验证的请求（通常是cookie）和基本身份验证），因此CSRF与浏览器是否可以对您进行身份验证无关。 cookie验证（如果不存在Bearer令牌）。我可能会看到类似的东西偶然进入应用程序的情况，并且由于无论您是否要发送cookie，cookie都会一起发送，这可能会导致在“本应是”不受干扰的页面上导致意外的CSRF漏洞。 CSRF。

结果，我想您的问题一和问题二可以用相同的方式回答。如果仅通过Bearer令牌而不是通过Cookie使用身份验证，则无需担心CSRF漏洞，并且无需采取额外步骤来保证安全性。

评论

说“只要您在标题中而不是通过cookie进行身份验证，就不必担心csrf保护”，这是不正确的。基本身份验证通过标头进行，并且容易受到csrf的攻击。同样，摘要身份验证，ntlm，协商和证书身份验证都容易受到crsf的攻击。每当浏览器自动发送身份验证时，都必须缓解CSRF，因为恶意的第三方可以简单地从用户浏览器向服务器发出请求，浏览器将自动发送凭据，因此如果没有“帮助”，服务器将无法区分。

–内森（Nathan）
19年1月6日在18:48
@Nathan我链接到的答案恰好提到了您的观点以及其中一些例外（实际上，我在答案中提到了基本身份验证作为例外）。我并不是要暗示“标头auth =安全”，而是“如果您设置标头以提供auth，那么您是安全的”。是的，浏览器（或身份验证服务器）将自动提供一些基于标头的身份验证系统，然后您就不必担心CSRF。

– Conor Mancone
19年1月6日在19:01


#2 楼

通常，当浏览器自动添加标头（即Cookie中的会话ID），然后对会话进行身份验证时，就会发生CSRF。承载令牌或需要手动添加的其他基于HTTP标头的令牌会阻止您使用CSRF。

当然，但是有些偏离主题，如果您具有XSS漏洞，攻击者仍然可以访问这些令牌，但它不会成为CSRF错误。

#3 楼

先前的答案是坚如磐石。我将跳到这里以提供更多背景信息和一些警告。使用JWT的方法很多。会话管理就是其中之一。尽管在处理超时和高级要求（如重新身份验证）时会带来一些缺陷。

此外，我还看到JWT放在Cookies中。正如其他人所述，CSRF保护并非来自使用JWT本身。它来自使用Bearer [JWT]方案作为授权标头提交的问题。


问题1：如果我要添加X-XSRF-Token标头，我会增加额外的安全性吗？ br />对于每个请求，例如通过检查JWT有效负载中的相同值，使该机制变为无状态？ （我已经在该线程中阅读了相关内容）


如果您是通过XHR作为Authorization标头提交的，那么没有多余的X-XSRF-Token标头不添加“额外”安全性。


问题2：我是否需要采取额外的安全措施来抵抗CSRF
吸收我描述的所有内容？


否，您当前的设置还可以。

前一段时间，我编写了一个Web身份验证技术指南及其安全属性（它也包含JWT部分）。这是最终的备忘单，以紧凑的形式描述了所有方法。

#4 楼

我觉得重要的是要强调一些有关单页应用程序（或通常来自任何前端的请求）的内容，这些内容可能会使CSRF保护无效。我以为乍一看这里可能有点题外话，但我正在重新考虑（请参阅底部的注释）。

我的观点：也许您有一些前端应用程序代码会自动使从URL加载应用程序后向API请求（最常见的示例之一是验证电子邮件地址）。在这种情况下，是否具有CSRF完全无关紧要。只要您的前端应用程序发生了某些事情而无需采取特定的用户操作，那么CRSF的保护就变得无关紧要，因为攻击者可以通过简单地打开您的前端应用程序就具有“合法”的方式来执行某些操作。

我想到了一些可能在前端自动执行的操作的示例


身份验证（生成访问令牌等）
验证电子邮件
跟随电子邮件链接自动对某些内容进行评级
（un）订阅电子邮件/新闻通讯
下载文件（如果前端应用在将下载请求转发到服务器之前进行了一些预处理）
加入一个项目，一个小组
验证引荐来源代码

其中一些用例（例如验证电子邮件）可能不需要身份验证且相对无害，而其他一些用例（例如加入一个小组）仅当您通过身份验证时才有意义，这意味着您可以通过某种方式自动执行身份验证针对API的请求。如果用户对发生的事情有一些直接的反馈（假设您的前端确实将反馈提供给用户），并且如果他们可以撤消这些操作，则可能不太危险。我们通常认为“ CSRF”是一种防止直接发送到服务器应用程序或API的请求的方法。如果我错了，请纠正我，但是定义似乎涵盖了任何攻击，其中恶意软件无法看到发生的结果，包括使用前端应用程序代码。