我们正在使用ASP.NET Core构建3个不同的应用程序MVC应用程序，API，SPA（不是Angular） . 此应用程序中的所有操作仅适用于授权用户 . 这就是我们用IdentityServer保护它们的原因 .
我们使用cookie来存储持票人令牌的 Value . 我知道cookie的值会自动发送到服务器 . 但是因为它应该作为授权 Headers 添加，所以浏览器不会自动完成 .
这是否可以减轻CSRF攻击的可能性？或者，对于承载令牌，CSRF仍然可行吗？我们还需要添加CSRF令牌吗？
2 回答
是的，您仍然需要CSRF令牌 .
如果您的SPA或MVC应用程序将根据用户的GET或POST操作向您的API发送请求，您仍需要CSRF令牌 .
假设有人欺骗您的用户点击触发SPA中的操作的链接，或者发布到您的MVC应用程序的链接，应用程序将很乐意遵守并发送存储在cookie中的持有者令牌作为请求标头，就像用户具有单击应用程序本身中的链接 .
这就是CSRF的重点，攻击者就像用户在您的Web应用程序中调用了一个动作一样制作请求 .
如果我理解你，MVC和SPA都会使用Identity Server对用户进行身份验证，并在主要cookie中存储令牌以访问API .
一般来说，这里有两种情况：
您的cookies是HTTP only（前端无法访问） . 然后将cookie发送到MVC和SPA服务器端，提取cookie并向API发送请求 . 在这种情况下，您可以像往常一样容易受到CSRF的攻击，因为您使用cookie进行了有效的身份验证，因此基于完全自动cookie身份验证的结果，对API进行令牌提取和承载身份验证 .
Cookies可在前端访问 . 在这种情况下，您可以使用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 .