X-Frame-Options: ALLOW-FROM в firefox и chrome

Я реализую "сквозной" для X-Frame-Options, чтобы сайт-партнер упаковывал сайт моего работодателя в iframe в соответствии с этой статьей: http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx

(разделение URL-адресов для публикации)

В двух словах наша страница-партнер имеет iframe с URL-адресом против нашего домена. Для любой страницы нашего домена они добавят специальный аргумент url, например &@mykey=topleveldomain.com, сообщая нам, что такое домен верхнего уровня страницы.

Наши фильтры забирают партнерский TLD, если он предоставлен, из URL-адреса и проверяют его по отношению к белым спискам. Если в списке мы отправим заголовок X-Frame-Options со значением ALLOW-FROM topleveldomain.com (и добавим файл cookie для будущих кликов). Если это не наш белый список, мы отправим SAMEORIGIN или DENY.

Проблема заключается в том, что отправка ALLOW-FROM domain приводит к отсутствию полной версии для последних версий Firefox и Google Chrome. IE8, по крайней мере, кажется, правильно реализует ALLOW-FROM.

Посмотрите эту страницу: http://www.enhanceie.com/test/clickjack. Сразу после 5-го (из 5) полей, которые должны показывать содержимое, это поле, которое НЕ должно показывать содержимое, но которое есть. В этом случае страница в iframe отправляет X-Frame-Options: ALLOW-FROM http://www.debugtheweb.com, сильно отличающийся TLD, чем http://www.enhanceie.com. Тем не менее, кадр по-прежнему отображает содержимое.

Любое понимание того, действительно ли X-Frame-Options реализовано с помощью ALLOW-FROM в соответствующих (настольных) браузерах? Возможно, синтаксис изменился?

Некоторые интересные ссылки:

Черновик rfc на x-frame-options: http://tools.ietf.org/html/draft-gondrom-frame-options-01
статья developer.mozilla обсуждает заголовок как заголовок с двумя параметрами (sameorigin или deny). https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
msdn blog, который инициировал все это: http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx
msdn blog, в котором говорится о 3 значениях: добавление разрешения-из источника http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx

Ответ 1

ALLOW-FROM не поддерживается в Chrome или Safari. См. Статью MDN: https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options

Вы уже выполняете работу по созданию настраиваемого заголовка и отправляете его с правильными данными, не можете ли вы просто исключить заголовок, когда обнаруживаете, что он принадлежит действующему партнеру, и добавьте DENY в каждый другой запрос? Я не вижу преимущества AllowFrom, когда вы уже динамически строите логику?

Ответ 2

Я разместил этот вопрос и никогда не видел обратной связи (которая появилась через несколько месяцев после этого, похоже:).

Как упоминал Кинлан, ALLOW-FROM не поддерживается во всех браузерах как значение X-Frame-Options.

Решение заключалось в ветвлении на основе типа браузера. Для IE отправьте X-Frame-Options. Для всех остальных, X-Content-Security-Policy.

Надеюсь, что это поможет, и извините за то, что вы так долго закрыли цикл!

Ответ 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);

в заголовки HTTP-ответа.

Обратите внимание, что это предполагает, что вы проверяли на сервере, разрешен ли refAuth.

Кроме того, обратите внимание, что вам необходимо выполнить обнаружение браузера, чтобы не добавлять заголовок allow-from для Chrome (выводит ошибку на консоли).

Подробнее см. мой ответ здесь.