三层应用程序是否需要 AntiForgeryToken？

Question

我的安全扫描检测到类型为“Missing AntiForgeryToken implementation”的问题。 我的应用程序有一层 .netCore WebApi 服务，一个带有 RazorPages 服务的 .netCore WebApi 和一个 Angular 前端应用程序。 在线阅读所有 CSRF Token 实现均指 RazorPages 或类似但不是前端应用程序。 问题是：三层架构是否需要令牌？ 我必须用我的 fe 实施该政策吗？ 该工具检测到的是真正的问题吗？

谢谢。

Answer 1

首先，有必要了解什么是antiforgerytoken？ 这与n层无关。 如果您的项目有 web 个页面并且您正在发出 http 次请求，您应该使用 AntiforgeryToken 以确保安全。

Answer 2

架构无关紧要。

“经验法则”是，如果您的应用程序中有用户上下文，那么您需要一个防伪令牌实现来防止攻击，例如：

攻击者使用恶意代码诱使用户访问另一个 web 页面（例如 evil.com），该恶意代码会秘密向应用程序的 web 服务器（例如 example-bank.com）发送恶意请求。

假设用户在 example-bank.com 登录到应用程序。 用户打开 email 并单击指向 evil.com 的链接，该链接将在新选项卡中打开。

evil.com 页面立即向 example-bank.com 发送恶意请求。 也许这是一个将钱从用户账户转移到攻击者账户的请求。 浏览器随此请求自动发送 example-bank.com cookies（包括身份验证 cookie）。

如果 example-bank.com 服务器缺乏 XSRF 保护，它就无法区分来自应用程序的合法请求和来自 evil.com 的伪造请求。

参考

Angular 的 HttpClient默认启用 XSRF Token 支持：

HttpClient 支持用于防止 XSRF 攻击的通用机制。 当执行 HTTP 请求时，拦截器从 cookie 中读取令牌，默认为 XSRF-TOKEN，并将其设置为 HTTP header，X-XSRF-TOKEN。 因为只有在您的域上运行的代码才能读取 cookie，后端可以确定 HTTP 请求来自您的客户端应用程序，而不是攻击者。

默认情况下，拦截器将此 header 发送到相对 URL 的所有变异请求（例如 POST），但不会发送到 GET/HEAD 请求或具有绝对 URL 的请求。

要利用这一点，您的服务器需要在页面加载或第一个 GET 请求时在名为 XSRF-TOKEN 的 JavaScript 可读 session cookie 中设置一个令牌。 在后续请求中，服务器可以验证 cookie 是否与 X-XSRF-TOKEN HTTP header 匹配，因此请确保只有在您的域上运行的代码才能发送请求。 令牌对于每个用户必须是唯一的，并且必须能够被服务器验证； 这可以防止客户端制作自己的令牌。 将令牌设置为您站点的身份验证 cookie 的摘要，并加盐以增加安全性。

参考

在 .net 端实施也相对直接。

services.AddAntiforgery(options => options.HeaderName = "X-XSRF-TOKEN");

Answer 3

底层架构并不重要。 真正的问题是您的 Angular 客户端如何对与之交谈的对象进行身份验证。

如果它使用浏览器自动发送的方法（通常像 cookies，但也例如 Windows auth / SPNEGO，这可能与您的堆栈相关），那么是的，您确实需要针对 CSRF 实施保护。

但是，如果您的身份验证是基于作为请求 header 发送的令牌（或者甚至在请求主体中，但重点是，浏览器不会自动），那么不，您的应用程序本质上不易受到典型的 CSRF 攻击，并且您不需要进一步的保护。