我们正在使用ASP.NET Core构建3个不同的应用程序MVC应用程序，API，SPA（不是Angular）。此应用程序中的所有操作仅适用于授权用户。这就是我们用IdentityServer保护它们的原因。
我们使用cookie来存储持票人令牌的价值。我知道cookie的值会自动发送到服务器。但是因为它应该作为授权标题添加，所以浏览器不会自动完成。
这是否可以减轻CSRF攻击的可能性？或者，对于承载令牌，CSRF仍然可行吗？我们还需要添加CSRF令牌吗？
答案 0 :(得分：3)
是的，你仍然需要CSRF代币。
如果您的SPA或MVC应用程序将根据用户的GET或POST操作向您的API发送请求，您仍需要CSRF令牌。
如果有人欺骗您的用户点击触发SPA中的操作的链接，或者发布到您的MVC应用程序的链接，应用程序将很乐意遵守并发送存储在Cookie中的持有者令牌作为请求标头，就像当用户单击了应用程序本身中的链接。
这就是CSRF的重点，攻击者制作请求就像用户在您的Web应用程序中调用了一个动作一样。
答案 1 :(得分：1)
如果我理解你，MVC和SPA都会使用Identity Server对用户进行身份验证，并在主要cookie中存储令牌以访问API。
一般来说，这里有两种情况：
您的Cookie为HTTP only（前端无法访问）。然后，您将cookie发送到MVC和SPA服务器端，提取cookie并向API发送请求。在这种情况下，您可以像往常一样容易受到CSRF的影响，因为您可以使用cookie进行有效身份验证，因此基于完全自动cookie身份验证的结果，可以对API进行令牌提取和承载身份验证。
Cookie可在前端访问。在这种情况下，您可以使用Javascript读取它们并将承载经过身份验证的请求发送到MVC和SPA服务器端（用于进一步传递给API）或直接发送到API，使所有后端忽略可能受到危害的cookie内容。 在这种情况下，您不容易受到CSRF的攻击（正如您所指出的那样，必须明确构建承载认证头）。但是，您很容易受到XSS（cross site scripting）的攻击：使用数据验证/卫生中的安全漏洞或简单的第三方依赖关系注入您的页面的任何代码都可以读取cookie并将其重新发送到任何服务器。这种情况与使用本地/会话存储非常相似，因此任何描述其漏洞的文章也适用于您的场景（例如here）。
因此，您必须在CSRF或XSS之间做出选择作为主要攻击。
使用防伪令牌可以完全防止CSRF，但如果你做不到，攻击就很容易组织起来。 由于您使用了大量第三方库，XSS在现代开发中很难完全防止（另一个XSS攻击向量 - 输入卫生通常不是一个问题，因为大多数MVC框架都是为了你默认like ASP NET Core）。但是，你很有可能避免它，这使得这个选项在许多情况下是e.g. Auth0 recommends it的合理选择。