当没有经过身份验证的用户时是否需要 CSRF 保护？
我们使用asp.net core和IdentityServer4开发了一个OpenId Connect服务器，并使用asp.net框架提供的跨站点请求伪造（CSRF）保护。
目前，我们向控制器添加了 [AutoValidateAntiforgeryToken] 属性，这为控制器内的所有 POST 端点添加了 CSRF 保护。
我知道在这些情况下需要 CSRF 保护：
- 对经过身份验证的用户的状态更改请求（因为浏览器可以自动将身份验证 cookie 添加到请求中）
- 提交登录用户的表单（以防止登录 CSRF）
但这是否会导致任何问题？对未经身份验证的用户使用的以下 POST 端点进行 CSRF 保护是否有意义？
- 忘记密码（提交应收到密码重置电子邮件的用户的用户名或电子邮件）
- 密码重置（提交新密码）
- 新用户注册
- 用户激活（提交密码和可能的其他个人数据）
We develop an OpenId Connect server with asp.net core and IdentityServer4 and we use cross-site requests forgery (CSRF) protection provided by the asp.net framework.
Currently, we add the [AutoValidateAntiforgeryToken] attribute to controllers, which adds the CSRF protection to all POST endpoints within the controller.
I understand that CSRF protection is needed in these cases:
- state-changing requests for authenticated users (because a browser could automatically add the auth cookie to the request)
- submitting forms that log the user in (to prevent Login CSRF)
But does it make any sense to have CSRF protection for following POST endpoints that are used by unauthenticated users?
- forgot password (submit username or email for the user who should receive a password reset email)
- password reset (submit new password)
- new user registration
- user activation (submit password and possibly additional personal data)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您尝试解决的问题是帮助服务器确定您收到的 POST 请求是否来自我生成的表单，而不是来自某个随机的黑客。
例如，如果黑客只是向您的“密码重置（提交新密码）”发送大量垃圾邮件请求，那么您的系统将开始发送大量密码重置电子邮件。因此，通过添加 CSRF，那些没有正确令牌的请求甚至不会执行。
因此，我会将其添加到您列出的所有端点中。例如，这也使得机器人更难尝试创建虚假帐户。
The problem that you try to solve is to help the server determine if the POST request that you receive came from a form I generated and not from some random hacker.
For example if a hacker would just sent a lot of spam requests to your "password reset (submit new password)", then your system would start to send out a lot of password reset emails. So by adding CSRF those request without a proper token would not even execute.
So, I would add it to all of the endpoints you listed. It also makes it harder for bots to try to create fake accounts for example.