X-Frame-Options: ALLOW-FROM 在火狐和谷歌浏览器中的作用

Question

我正在实现一个“穿透”，针对X-Frame-Options，让合作伙伴的站点在iframe中包裹我的雇主的站点，正如这篇文章所述：http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx 简而言之，我们合作伙伴的页面有一个针对我们域名的iframe URL。 对于我们域中的任何页面，他们都会添加一个特殊的url参数，例如&@mykey=topleveldomain.com，告诉我们页面的顶级域是什么。

我们的过滤器从URL中提取并验证提供的合作伙伴TLD是否在白名单中。如果在列表中，我们将使用值为ALLOW-FROM topleveldomain.com的X-Frame-Options头（并添加一个cookie以供未来使用）。如果不在我们的白名单中，我们会发送SAMEORIGIN或DENY。

问题在于最新版本的 Firefox 和 Google Chrome 发送 ALLOW-FROM domain 看起来结果是整体无操作。至少 IE8 正确地实现了 ALLOW-FROM。请查看此页面：http://www.enhanceie.com/test/clickjack。在第五个（共 5 个）“应显示内容”的框后面，有一个不应该显示内容但却显示了内容的框。在这种情况下，iframe 中的页面正在发送 X-Frame-Options: ALLOW-FROM http://www.debugtheweb.com，它与http://www.enhanceie.com 是完全不同的 TLD。 但是，frame 仍然显示内容。

是否有任何深入了解 X-Frame-Options 在相关（桌面）浏览器中是否真正实现了 ALLOW-FROM 的见解？也许语法已更改？

一些有用的链接:

• 草案rfc关于x-frame-options: https://datatracker.ietf.org/doc/html/draft-gondrom-frame-options-01
• developer.mozilla的文章讨论了该头作为2个选项头（sameorigin或deny）https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
• msdn博客发起整个事情：http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx
• msdn博客谈到3个值：添加allow-from originhttp://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx

- Rob

---

如果你自己发现了更多的东西，欢迎发布你自己的答案。我会给你点赞！ - Prestaul

昨天为Firefox添加了一个补丁：https://bugzilla.mozilla.org/show_bug.cgi?id=690168 我们将看到它是否通过审核并很快出现在您附近的浏览器中... - Prestaul

老问题，但为了后世记录 - 你所描述的方法（将TLD作为iframe的参数传递）很容易被想要嵌入您内容的任何人轻松地打败。他们只需查看源代码，查看您的操作，并复制/粘贴。由于ALLOW-FROM尚不可靠，因此您可以使用共享密钥，该密钥与当前时间（在窗口内）进行加密哈希并包含在iframe URL中。在iframe侧，验证散列共享密钥。内容盗贼可能会窃取该哈希，但仅在短时间内有效，从而有效地阻止未经授权的嵌入。 - Mark

Answer 1

在Chrome和Safari中不支持ALLOW-FROM。请参阅MDN文章：https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options

您已经在做工作，以制作自定义标头并使用正确的数据发送它，当检测到来自有效合作伙伴时，您是否可以不包含该标头，并向每个其他请求添加DENY？我看不出AllowFrom的好处，因为您已经动态构建了逻辑。

- Kinlan

---

他正在实现链接的 MSDN 页面上 Tokens 标题下的 4 步安全措施，不幸的是这在 Chrome 和 Safari 中无法工作。 - rbrc

是的，我知道，所以我建议反过来做。 - Kinlan

他将会查看"referer"请求头，这是一个不错的方式，尽管"referer"伪造仍然很常见。如果所有相关页面都采用HTTPS协议，则这种方式就变得更加困难。使用"AllowFrom"肯定更可取。 - rbrc

抱歉，编辑删除了我的解释！我们决定不使用来自客户端的 HTTP_REFERER 作为判断依据，因为它是不可靠的机制。此外，我们发现一些浏览器（我相信特别是 IE）不会从包含顶级 iframe 的页面传递 HTTP_REFERER，所以我们没有可靠的方法从服务器端确定谁在将我们嵌入框架中。 - Rob

来自客户端的URL参数也是不可靠的机制，因为它来自客户端。 - Sven

Answer 2

我发布了这个问题，但在几个月后才看到反馈（好像是这样的 :）。

正如Kinlan提到的，ALLOW-FROM不是所有浏览器都支持作为X-Frame-Options值。

解决方案是基于浏览器类型进行分支。对于IE，使用X-Frame-Options。对于其他所有人，使用X-Content-Security-Policy。

希望这可以帮助您，很抱歉让您等待那么久才得到答复！

- Rob

---

目前的 X-Content-Security-Policy 没有为 ALLOW-FROM 提供跨浏览器的类似物。Firefox 支持 frame-ancestors，而即将推出的规范支持 frame-options。目前，Chrome 只在运行时标志后面支持这些 frame-ancestors。frame-src 可用，但是这是父框架控制子框架，而不是子框架指定其允许的父级。 - JT.

2018年更新：Content-Security-Policy现在得到了良好的支持。 - rinogo

Answer 3

对于Chrome，不要

response.AppendHeader("X-Frame-Options", "ALLOW-FROM " + host);

你需要添加Content-Security-Policy

string selfAuth = System.Web.HttpContext.Current.Request.Url.Authority;
string refAuth = System.Web.HttpContext.Current.Request.UrlReferrer.Authority;
response.AppendHeader("Content-Security-Policy", "default-src 'self' 'unsafe-inline' 'unsafe-eval' data: *.msecnd.net vortex.data.microsoft.com " + selfAuth + " " + refAuth);

将allow-from头部信息添加到HTTP响应头中。请注意，这假设您在服务器上检查了refAuth是否允许。此外，请注意，您需要进行浏览器检测，以避免为Chrome添加allow-from头部（在控制台上输出错误）。有关详细信息，请参见我的回答。

- Stefan Steiger

---

如果你想避免点击劫持，可以使用内容安全策略(Content-Security-Policy)，但绝不能通过添加"default-src"属性来实现，因为这会产生完全不同的效果。你需要使用"frame-ancestors"，它类似于X-Frame-Options，但更加灵活，可以指定多个域名。参见：https://martijnvanlambalgen.wordpress.com/2015/06/28/clickjacking/ - Myrddin81