Вопрос по – Опции X-Frame: ALLOW-FROM в Firefox и Chrome

57

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

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

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

Наши фильтры выбирают TLD партнера, если таковой имеется, из URL и проверяют его по белому списку. Если это в списке, мы отправляемX-Frame-Options заголовок со значениемALLOW-FROM topleveldomain.com (и добавить куки для будущих кликов). Если его нет в нашем белом списке, мы отправляем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определенно другой домен верхнего уровня, чемhttp://www.enhanceie.com, Тем не менее, кадр по-прежнему отображает содержимое.

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

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

Draft rfc on x-frame-options: http://tools.ietf.org/html/draft-gondrom-frame-options-01 developer.mozilla article discussing the header as a 2-option header (sameorigin or deny). https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options msdn blog that initiated the whole thing: http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx msdn blog that talks about 3 values: adding allow-from origin http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx
Вчера был добавлен патч для Firefox:bugzilla.mozilla.org/show_bug.cgi?id=690168  Мы посмотрим, удастся ли это сделать в ближайшее время через браузер ... Prestaul
Старый вопрос, но для потомков - метод, который вы описали (передача TLD в качестве аргумента для iframe), будет очень легко побежден любым, кто захочет встроить ваш контент. Они просто просматривают источник, видят, что вы делаете, и копируете / вставляете. Поскольку ALLOW-FROM еще не надежен, вы можете использовать общий секретный ключ, который криптографически хешируется с текущим временем (в пределах окна) и включается в URL-адрес iframe. На стороне iframe проверьте хешированный общий секрет. Воры контента могут украсть этот хеш, но он будет работать только для краткого окна, эффективно блокируя несанкционированные встраивания. Mark
Если вы придумаете что-нибудь более самостоятельно, то не стесняйтесь опубликовать свой собственный ответ. Вы получите от меня ответ! Prestaul

Ваш Ответ

3   ответа
16

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

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

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

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

Error: User Rate Limit ExceededContent-Security-Policy is now well-supported.
Error: User Rate Limit ExceededX-Content-Security-PolicyError: User Rate Limit ExceededALLOW-FROMError: User Rate Limit Exceededframe-ancestorsError: User Rate Limit Exceededframe-optionsError: User Rate Limit Exceededframe-ancestorsError: User Rate Limit Exceededframe-srcError: User Rate Limit Exceeded
35

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

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

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Rob
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Rob
5

Для 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 (выводит ошибку на консоль).

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

Error: User Rate Limit Exceededmartijnvanlambalgen.wordpress.com/2015/06/28/clickjacking

Похожие вопросы