CSRF 保护仅适用于具有副作用的请求（POST、DELETE、PUT）？
据我了解，跨站点请求伪造攻击“仅”用于更改服务器端的状态。
假设：
- 我有一个 REST Web 应用程序，并且我确信 HTTP GET 请求不会更改我的应用程序持久状态（无副作用）
- 我使用会话特定密钥来授权请求
我是否需要验证会话特定密钥对于 GET 请求？
As far I understand Cross-Site Request Forgery attacks they "only" used to change state on Server side.
Assume:
- I have a REST Web Application, and I am sure that HTTP GET requests does not change my application persistent state (no side effects)
- I use a session-specific key to authorize the requests
Do I need to verify the session-specific key for GET Request?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这实际上并不是请求方法的问题（GET 和 POST 都可以更改持久状态），因为每种方法都可以被各种 CSRF 攻击向量利用。当您谈论“会话特定密钥”时，我假设您正在谈论同步器令牌模式（更多信息请参见 面向 .NET 开发人员的 OWASP Top 10 第 5 部分：跨站点请求伪造 (CSRF))。显然，这是为了防止浏览器在第三方的协调下代表您发出未经授权的请求。
所以问题实际上是“我的应用程序需要针对 CSRF 的保护吗？”听起来您的应用程序中的持久数据无论如何都没有改变，所以从表面上看，答案是“否”。您通常只会在 CSRF 攻击会产生不利影响的地方找到反请求伪造令牌，因此在我看来，您不需要担心这一点。
It's not really a question of the request method (GET and POST can both make changes to persistent state), as each can be exploited by various CSRF attack vectors. When you talk about a "session-specific key", I assume you're talking about a synchroniser token pattern (more on this in OWASP Top 10 for .NET developers part 5: Cross-Site Request Forgery (CSRF)). Obviously this is intended to protect against the browser making unauthorised requests on your behalf under the orchestration of a third party.
So the question is really "Does my app require protection against CSRF?" It sounds like there's no change to persistent data in your app anyway so on the surface of it, the answer is "no". You generally only find anti-request forgery tokens in places where a CSRF attack would have an adverse impact so it sounds to me like it's something you don't need to worry about.