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
в соответствующих (настольных) браузерах? Возможно, синтаксис изменился?
Некоторые интересные ссылки:
Ответы
Ответ 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 (выводит ошибку на консоли).
Подробнее см. мой ответ здесь.