使用您网站的身份验证 cookie 的摘要进行 CSRF
Using digest of your site's authentication cookie for CSRF
我想保护我的 WebApi 端点免受 CSRF 攻击。 Angular 团队建议使用您网站的身份验证 cookie 的摘要和 salt 以增加安全性。我不确定与随机令牌相比这里有什么优势。更重要的是，你们如何保护登录页面？
这里解释为什么你需要保护登录页面https://security.stackexchange.com/questions/2120/when-the-use-of-a-antiforgerytoken-is-not-required-needed
您描述的方法是 detailed here:
Cross Site Request Forgery (XSRF) Protection XSRF is a technique by
which an unauthorized site can gain your user's private data. Angular
provides a mechanism to counter XSRF. When performing XHR requests,
the $http service reads a token from a cookie (by default, XSRF-TOKEN)
and sets it as an HTTP header (X-XSRF-TOKEN). Since only JavaScript
that runs on your domain could read the cookie, your server can be
assured that the XHR came from JavaScript running on your domain. The
header will not be set for cross-domain requests.
To take advantage of this, your server needs to set a token in a
JavaScript readable session cookie called XSRF-TOKEN on the first HTTP
GET request. On subsequent XHR requests the server can verify that the
cookie matches X-XSRF-TOKEN HTTP header, and therefore be sure that
only JavaScript running on your domain could have sent the request.
The token must be unique for each user and must be verifiable by the
server (to prevent the JavaScript from making up its own tokens). We
recommend that the token is a digest of your site's authentication
cookie with a salt for added security.
The name of the headers can be specified using the xsrfHeaderName and
xsrfCookieName properties of either $httpProvider.defaults at
config-time, $http.defaults at run-time, or the per-request config
object.
In order to prevent collisions in environments where multiple Angular
apps share the same domain or subdomain, we recommend that each
application uses unique cookie name.
这似乎是 Encrypted Token Pattern CSRF prevention method 的一个变体，使用散列而不是加密，盐的作用类似于密钥。
它还依赖于防止自定义 headers 跨域发送的 HTTP 功能，就像添加 X-Requested-With 一样。
声明 "an unauthorized site can gain your user's private data" 的部分有点误导，因为 CSRF 不允许直接这样做 - CSRF 攻击允许未经授权的网站在当前登录用户的上下文中提交您网站的表单。
这种方法的一个优点是你不需要在服务器端保存任何额外的东西。例如，如果您使用 token-based 身份验证，您可以通过应用具有 server-side salt 的相同散列来轻松验证收到的 CSRF 令牌是否与 cookie 匹配。即使您使用 cookie-based 身份验证，您也不需要根据存储的单独值 server-side 验证 CSRF 令牌 - 您只需散列 cookie 值以验证它是否与传递的令牌匹配。
请参阅 this answer 了解如何防止登录 CSRF。
我想保护我的 WebApi 端点免受 CSRF 攻击。 Angular 团队建议使用您网站的身份验证 cookie 的摘要和 salt 以增加安全性。我不确定与随机令牌相比这里有什么优势。更重要的是，你们如何保护登录页面？
这里解释为什么你需要保护登录页面https://security.stackexchange.com/questions/2120/when-the-use-of-a-antiforgerytoken-is-not-required-needed
您描述的方法是 detailed here:
Cross Site Request Forgery (XSRF) Protection XSRF is a technique by which an unauthorized site can gain your user's private data. Angular provides a mechanism to counter XSRF. When performing XHR requests, the $http service reads a token from a cookie (by default, XSRF-TOKEN) and sets it as an HTTP header (X-XSRF-TOKEN). Since only JavaScript that runs on your domain could read the cookie, your server can be assured that the XHR came from JavaScript running on your domain. The header will not be set for cross-domain requests.
To take advantage of this, your server needs to set a token in a JavaScript readable session cookie called XSRF-TOKEN on the first HTTP GET request. On subsequent XHR requests the server can verify that the cookie matches X-XSRF-TOKEN HTTP header, and therefore be sure that only JavaScript running on your domain could have sent the request. The token must be unique for each user and must be verifiable by the server (to prevent the JavaScript from making up its own tokens). We recommend that the token is a digest of your site's authentication cookie with a salt for added security.
The name of the headers can be specified using the xsrfHeaderName and xsrfCookieName properties of either $httpProvider.defaults at config-time, $http.defaults at run-time, or the per-request config object.
In order to prevent collisions in environments where multiple Angular apps share the same domain or subdomain, we recommend that each application uses unique cookie name.
这似乎是 Encrypted Token Pattern CSRF prevention method 的一个变体，使用散列而不是加密，盐的作用类似于密钥。
它还依赖于防止自定义 headers 跨域发送的 HTTP 功能，就像添加 X-Requested-With 一样。
声明 "an unauthorized site can gain your user's private data" 的部分有点误导，因为 CSRF 不允许直接这样做 - CSRF 攻击允许未经授权的网站在当前登录用户的上下文中提交您网站的表单。
这种方法的一个优点是你不需要在服务器端保存任何额外的东西。例如，如果您使用 token-based 身份验证，您可以通过应用具有 server-side salt 的相同散列来轻松验证收到的 CSRF 令牌是否与 cookie 匹配。即使您使用 cookie-based 身份验证，您也不需要根据存储的单独值 server-side 验证 CSRF 令牌 - 您只需散列 cookie 值以验证它是否与传递的令牌匹配。
请参阅 this answer 了解如何防止登录 CSRF。