如果标头中的验证令牌而不是 POST 正文中的 CSRF 安全风险
关于搜索 CSRF 预防技术最广泛找到的解决方案是 MVCAntiForgeryToken （随 MVC 3 一起提供）实现，其中客户端服务器必须在 POST 正文中发布验证令牌。在服务器端，它将根据 Cookie 中存在的令牌进行验证。
在自定义标头中发送验证令牌，并在服务器端验证自定义令牌的值与 cookie 中存在的值是否同样安全？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
它甚至更安全:)，因为即使攻击者可以获得当前事务的有效 csrf 令牌，他也必须发起跨域 ajax 请求以在请求中包含自定义标头。如果用户在浏览器中禁用了 js，那么攻击者就会被干掉:)。然而，它可以被java小程序覆盖......但你知道，如果用户没有受过教育并且攻击者确实有动机，那么你几乎无能为力；）。
但存在一个问题，如果用户通过防火墙或公司代理访问我们，则并非所有自定义标头都会被转发。所以我认为这是使用字段而不是自定义标头的主要原因。尽管有一个标头可以防止 XSRF 攻击：Origin、网络起源概念也作为附加信息内容安全政策 1.1 这只是一个草案，但其中提出了一些有趣的想法。
It is even more secure :) because even if attacker can obtain a valid csrf token for current transaction, he would have to institute a cross domain ajax request to include custom headers in request. And if user has disabled js in his browser then the attacker is toasted :). It can however be overridden with java applets... but you know if users are uneducated and attacker is really motivated there is very little you can do;).
But there is an issue not all custom headers will be forwarded in case a user is accessing us via firewall or corporate proxy. So i think this is the main reason for using field instead of a custom header. Although there is a header that prevents XSRF attacks: Origin, The web origin concept also as additional information Content Security Policy 1.1 it is only a draft but some interesting ideas are presented there.