ASP.NET MVC ValidateAntiForgeryToken — 可以用授权检查和推荐人检查代替吗？

Question

在 ASP.NET MVC 中有一个 ValidateAntiForgeryToken 属性，可以启用跨站点脚本防御。

是否可以将这种机制替换为

• 授权检查，包括检查被操纵的资源是否属于当前用户；
• referrer 检查，将禁止来自外部主机的 AJAX Web api 请求；
• 禁止在 iframe 中托管的网站？

Answer 1

这不会阻止cross site scripting，只会阻止cross site request forgery。

授权检查，包括检查被操纵的资源是否属于当前用户；

不，因为资源确实属于当前用户，只是当前用户没有主动提出的请求。

例如在您的网站www.foo.com 上说您有以下 URL，该 URL 将删除用户的帐户。

www.foo.com/DeleteAccount

您的用户已登录到www.foo.com。现在假设您的用户访问了www.evil.com，其中包含页面上的以下图像标签。

<img src="http://www.foo.com/DeleteAccount" />

这将向您的页面发出请求并删除用户的帐户，因为 DeleteAccount 资源将通过 cookie 检查授权并确定用户确实已获得授权，因为请求提供了 auth cookie。

referrer 检查，将禁止来自外部主机的 AJAX web api 请求；

是的，这是一个有效的检查，尽管它比您问题中提到的使用防伪令牌的方法弱。

OWASP CSRF Cheat Sheet 状态

虽然在您自己的浏览器上欺骗referer 标头很简单，但在CSRF 攻击中是不可能做到的。检查引用是在嵌入式网络设备上防止 CSRF 的常用方法，因为它不需要每个用户的状态。当内存不足时，这使得引用者成为防止 CSRF 的有用方法。这种缓解 CSRF 的方法也常用于未经身份验证的请求，例如在建立会话状态之前发出的请求，该会话状态需要跟踪同步令牌。

但是，检查引用者被认为是 CSRF 保护较弱的。例如，开放重定向漏洞可用于利用受引用者检查保护的基于 GET 的请求。应该注意的是，GET 请求不应该引起状态更改，因为这违反了 HTTP 规范。 引用者检查也存在常见的实现错误。例如，如果 CSRF 攻击源自 HTTPS 域，则引用者将被省略。在这种情况下，当请求执行状态更改时，应将缺少引用者视为攻击。另请注意，攻击者对引用者的影响有限。例如，如果受害者的域是“site.com”，那么攻击者的 CSRF 漏洞来自“site.com.attacker.com”，这可能会欺骗一个损坏的引用检查实现。 XSS 可用于绕过referer 检查。

另请注意，有时并不总是传递引荐来源网址，因为用户可能正在使用删除标题的隐私软件。

禁止在 iframe 中托管的网站？

这可以有效防御您托管的小部件被包含在其他网站上。

例如www.bar.com 可以通过使用script 标签在他们的页面上包含您的小部件：

<script src="//www.foo.com/widget.js"></script>

为了防止 www.bar.com 在您的小部件中提交表单，您的 JavaScript 代码会将 document.write 一个 IFrame 放入页面，然后将您的内容包含在其中。 Same Origin Policy 将阻止父页面读取 IFrame 内容，然后包含您的小部件的站点无法提交您的表单。但是，在这里您可能需要在任何点击的情况下弹出手动确认窗口以防止click jacking 攻击（例如，如果您有一个 like 按钮（类似于 Facebook）并且您想阻止从自动提交表单的包含页面伪造likes）。

OWASP 推荐

OWASP Recommendation 是使用Synchronizer Token Pattern，这是由 ASP.NET MVC 实现的ValidateAntiForgeryToken。