问题标签 [antiforgerytoken]

我正在尝试保护应用程序（php 和大量 JS）免受 CSRF 的影响。

我想使用令牌。

很多操作都是用 AJAX 完成的，所以我必须在 Javascript 中传递令牌。如果我想为每个会话或每个页面加载生成 1 个令牌，这很简单 - 我生成新令牌，将其放在 DOM 中的某个位置，然后使用 Javascript 找到它并发送到处理端。

但是，如果我想为每个操作使用新令牌怎么办？我正在考虑进行 ajax 调用以重新生成令牌，然后将结果传递给处理页面。

这会增加安全风险吗？我正在考虑用脚本来引诱用户页面，该脚本会要求令牌，然后使用它来发出请求，但随后再次禁止跨域 Javascript。可以用闪光灯做吗？

也许是另一种保护 ajax 调用免受 CSRF 影响的方法？

谢谢！

我的问题的一些背景：

Mvc2 中似乎有一个关于ValidateAntiForgeryTokenAttribute.

从 Mvc1 升级到 Mvc2 时，具有活动会话的用户在使用以下命令请求页面时将收到以下错误ValidateAntiForgeryTokenAttribute：

无法将“System.Web.UI.Triplet”类型的对象转换为“System.Object[]”类型。

此处记录了该问题。

升级到 Mvc2 后，我们预计我们将受到此问题的严重影响。我已经编写了从评论中的代码派生的修复程序（为后代记录在下面）。目前，通过创建一个子类Controller并AsyncController覆盖 Initialize 方法来调用此代码以纠正问题。例如

这样做的连锁反应是我必须更改我的所有控制器类以从我新的、更正的控制器子类派生。对于打算在大约一个月的时间内弃用的代码来说，这似乎非常具有侵入性。

所以，说到我的问题，我想知道是否有一种侵入性较小的方法来修补现有类，这样就不必改变类的下游用户，也许使用反射？

我们收到“未提供所需的防伪令牌或该令牌无效”。错误，在进一步的调查中，我设法以最简单的形式重现了这个问题——我要么做错了，要么这是防伪令牌系统的限制。

无论哪种方式，我都会很感激一些建议！

空的 MVC 2 项目：一个视图页面，一个控制器

看法：

控制器：

[编辑：简化代码示例]

为了重新创建例外，请打开两个未登录的选项卡 - 在第一个选项卡上登录，然后在第二个选项卡上登录。

当我猜测正确的行为是重定向到登录页面时，第二个选项卡将始终引发防伪异常（共享原始登录选项卡的会话/身份验证）

任何意见，将不胜感激！

干杯，戴夫

根据我在互联网上的一些博客文章中阅读的信息，我已经在我的应用程序中实现了对CSRF 攻击的缓解。特别是这些帖子是我实施的驱动力

• 来自 ASP.NET 和 Web 工具开发人员内容团队的 ASP.NET MVC 最佳实践
• Phil Haack 博客的跨站点请求伪造攻击剖析
• ASP.NET MVC 框架中的 AntiForgeryToken - David Hayden 博客中的 Html.AntiForgeryToken 和 ValidateAntiForgeryToken 属性

基本上这些文章和建议说，为了防止 CSRF 攻击，任何人都应该实现以下代码：

1. 添加[ValidateAntiForgeryToken]接受 POST Http 动词的每个动作

   [HttpPost] [ValidateAntiForgeryToken] public ActionResult SomeAction( SomeModel model ) { }

2. <%= Html.AntiForgeryToken() %>在向服务器提交数据的表单中添加助手

无论如何，在我的应用程序的某些部分，我正在使用 jQuery 向服务器发送 Ajax POST，根本没有任何形式。例如，当我让用户单击图像以执行特定操作时，就会发生这种情况。

假设我有一张包含活动列表的表格。我在表格的一列上有一张图片，上面写着“将活动标记为已完成”，当用户单击该活动时，我正在执行 Ajax POST，如下例所示：

<%= Html.AntiForgeryToken() %>在这些情况下我该如何使用？我应该在 Ajax 调用的 data 参数中包含辅助调用吗？

对不起，很长的帖子，非常感谢您的帮助

编辑：

根据jayrdub的回答，我使用了以下方式

前段时间我遇到了 Uploadify 插件的问题，我确实找到了这个答案中描述的解决方案。

该问题中的问题主要是由于 Uploadify 使用了 flash 插件，并且 flash 插件不与服务器端代码共享身份验证 cookie。

解决方案是使用 Authorize 属性的自定义版本（代码已在该答案中发布）。

属性 [TokenizedAuthorize] 被放置在控制器类上，如下所示

几天前，我添加了<%: Html.AntiForgeryToken() %>表单内部和 [ValidateAntiForgeryToken]操作方法，如下例所示：

无论如何，我不再能够将文件上传到服务器。使用调试器，我已经能够在TokenizedAuthorize代码的最后一行之后检查

我得到一个由 Elmah 处理的异常，上面写着

此异常似乎确认[ValidateAntiForgeryToken]正在调用该属性......但我不明白我的代码问题出在哪里。

有什么帮助吗？

编辑：

使用调试器，我检查了__RequestVerificationToken表单参数的值，如您所见，它正确地填充了来自的值<%: Html.AntiForgeryToken() %>

编辑 2：

我还可以确认，如果我[ValidateAntiForgeryToken]对 Post Action 发表评论，一切都会按预期进行

编辑 3：

由于 post 函数是由 uploadify 插件完成的 ajax 调用，因此使用一个小的 js 函数将 AntiForgeryToken 添加到 post 参数中，如下面的代码所示

AddAntiForgeryToken()我的母版页中定义的 javascript 函数在哪里支持所有 ajax 发布到服务器

编辑 4：

达林的直觉是正确的。Uploadify 脚本没有向服务器发送任何 cookie，因此服务器无法验证 AntiForgeryToken。如何在 Uploadify scriptData 部分中添加 cookie？

我想使用 AntiForgeryToken 函数，但 AcceptVerbs 帖子不适用。我收到防伪错误。有没有办法在没有 post 方法的情况下做到这一点？

UPD：在security.stackexchange.com上提出了同样的问题，我得到的答案不同。请关注那里，以获得正确答案！

我正在运行一个相当大的网站，每天有数千次访问，以及相当大的用户群。

自从我开始迁移到 MVC 3 以来，我一直将 AntiForgeryToken 置于多种形式中，用于修改受保护的数据等。

其他一些形式，比如登录/注册现在也使用 AntiForgeryToken，但我开始怀疑他们的需求，原因有几个......

1. 登录表单要求发布者知道正确的凭据。我真的想不出 csrf 攻击会从中受益的任何方式。特别是如果我检查请求是否来自同一主机（检查引荐来源标头）
2. 每次加载页面时，AntiForgeryToken 令牌都会生成不同的值。如果我在登录页面打开了两个选项卡，然后尝试发布它们，第一个将成功加载。第二个将失败并出现 AntiForgeryTokenException（首先加载两个页面，然后尝试发布它们）。使用更安全的页面 - 这显然是一个必要的邪恶，对于登录页面 - 似乎有点矫枉过正，只是自找麻烦：S

可能还有其他原因导致人们在他们的表单中使用/不使用令牌。我是否正确假设在每个帖子表单中使用令牌都是不好的/矫枉过正的，如果是这样 - 什么样的表单会从中受益，哪些肯定不会受益？

我正在尝试防止 CSRF 并有两个场景：

1. 从另一个站点内进行 POST 并在我启用 AntiForgeryToken 时失败
2. 我已经尝试从我的“恶意”Javascript（在另一个站点上运行）首先执行页面的 GET，解析它并提取 RequestVerificationToken，然后执行 POST。这也失败了，但我不清楚为什么？

谁能解释一下为什么？

关于这个 Haacked 博客，我对实施建议的反 JSON GET 劫持解决方案犹豫不决，因为

1. 减轻 JSON 劫持的推荐解决方案涉及到 GET 数据的非 REST-full JSON POST

2. 替代解决方案（对象包装）会导致我无法访问源代码的第 3 方控件出现问题。

3. 我找不到一个经过社区审查的实现，它实现了关于如何编写安全令牌或在网页中安全地交付它的替代解决方案（如下所列）。我也不会声称有足够的专家来推出我自己的实现。

4. 不能依赖引用标题

背景

这篇博客描述了一个关于 JSON 劫持的 CSRF 问题，并建议使用 JSON POST 来获取数据。由于使用 HTTP POST 来获取数据不是 REST 完整的，因此我正在寻找一种更 REST 完整的解决方案，该解决方案可以在每个会话或每个页面上启用 REST 操作。

另一种缓解技术是将 JSON 数据包装在一个对象中，如此处所述。恐怕这可能只会延迟问题，直到找到另一种技术。

替代实施

对我来说，为我的 JSON 扩展使用ASP.NET MVC 的 AntiForgeryToken和 jQuery HTTP GET似乎很自然。

例如，如果我 GET 一些敏感数据，根据上面的 Haacked 链接，以下代码很容易受到攻击：

我同意使用推荐的 POST 解决方法获取数据不是 RESTfull。我的想法是在 URL 中发送一个验证令牌。这样 CSRF 风格的攻击者就不会知道完整的 URL。缓存或未缓存，他们将无法获取数据。

下面是如何完成 JSON GET 查询的两个示例。我不确定哪种实现最有效，但可能会猜测第一个更安全，因为错误的代理缓存了这些数据，从而使其容易受到攻击者的攻击。

http://localhost:54607/Home/AdminBalances/ENCODEDTOKEN-TOKEN-HERE

或者

http://localhost:54607/Home/AdminBalances?ENCODEDTOKEN-TOKEN-HERE

...这也可能是 MVC3 的 AntiForgeryToken 或其变体（参见 swt）。此标记将设置为上面选择的任何 URL 格式的内联值。

阻止我推出自己的解决方案的示例问题

1. 您将使用什么 URL 格式（上图）来验证 JSON GET（斜杠、问号等） 代理是否会使用http ://localhost:54607/Home/AdminBalances 响应http://localhost:54607/Home/AdminBalances？ ENCODEDTOKEN-TOKEN-HERE数据？

2. 您将如何将该编码令牌传递到网页？内联，还是作为页面变量？

3. 您将如何编写令牌？内置 AntiforgeryToken，还是通过其他方式？

4. AntiForgeryToken 使用 cookie。在这种情况下是否会使用/需要支持 cookie？仅 HTTP？SSL 与仅 HTTP 结合使用如何？

5. 您将如何设置缓存标头？Google Web Accelerator 的任何特殊功能（例如）

6. 仅使 JSON 请求 SSL 有什么含义？

7. 为了安全起见，返回的 JSON 数组是否仍应包装在一个对象中？

8. 此解决方案将如何与 Microsoft 提出的模板和数据绑定功能互操作

上面的问题是我自己不进取并这样做的原因。更不用说可能还有更多我没有想到的问题，但这些问题仍然存在风险。

AntiForgeryToken 用于防止 CSRF 攻击，但是 MSDN 上的链接并没有让我深入了解 AntiForgeryToken 究竟是做什么的，或者它是如何工作的，或者为什么事情会以它们的方式完成。

据我所知，它在网页和 cookie 中创建了一个哈希。它们中的一个或两个都使用 hashed IPrincipal.Name，并使用对称加密。

任何人都可以阐明：

1. AntiForgeryToken 如何在内部工作
2. 它应该用来保护什么
3. 它不应该用来保护什么
4. 上述#1 的实施选择背后的原因是什么？
   • 例子：
     • 实施是否不受“DoubleSubmit”cookie 和其他常见漏洞的影响
     • 如果用户打开多个选项卡，是否存在实施问题
     • 是什么让 MSFT 的实施与 SANS 的实施不同