Как разрешить только белые ресурсы (сценарии, пиксели и т.д.) Для запуска в изолированном iframe?

Я ищу подход, позволяющий запускать только белые списки в изолированном iframe. Я думал о директиве iframe-sandbox, которая позволяет запускать только белые списки в пределах iframe. Аналогом является директива script-src в Политике безопасности контента.

Эта проблема:

<iframe sandbox="allow-same-origin allow-scripts" src="https://app.thirdparty.com" width="100%" height="800" frameBorder="0"></iframe>

Приложение в iframe предоставляет ценные функции для моего сайта. Однако он привлекает внешние ресурсы, которые я бы хотел контролировать (т.е. Блокировать), например, AnalyticsJavaScript.com и TrackingPixel.com. Я хотел бы разрешить сценарии из app.thirdparty.com, но блокировать AnalyticsJavaScript.com и TrackingPixel.com.

Любая помощь оценивается.

ОТВЕТЫ

Ответ 1

Ответ на это, к сожалению, сложный. С появлением песочницы iframe вопрос кажется достаточно простым, но спецификация, которую вы ищете, - это очень большая работа. Таким образом, если вы хотите достойную поддержку браузера, проблема связана с тем, как изменить содержимое iframe, которое обычно связано с каким-то прокси-сервером.

Политика безопасности контента

Спецификой, в которой вы действительно нуждаетесь, является CSP. В простейшем случае вы разрешаете конкретные сценарии с атрибутом iframe csp csp="...".

<iframe ...
        src=""
        csp="script-src https://app.thirdparty.com/"
        ...></iframe>

Любые скрипты из доменов, не указанных (например, скрипты отслеживания, как в вопросе), не будут разрешены в ответе. Обратите внимание, что ограничение сценариев для файлов из указанного источника зависит от сотрудничества с сервером сторонних приложений. Если сервер не сообщает пользовательскому агенту, что он будет придерживаться ограничений CSP, ответ будет заблокирован.

CSP по-прежнему является рабочим проектом и может измениться в будущем. Как указано в комментариях, Chrome 61 и Opera 48 внедрили спецификацию CSP, но на этом этапе нет никаких признаков из Firefox, Edge или Safari, которые они также будут реализовывать. Если вы не можете гарантировать, что ваши пользователи будут использовать только браузер, поддерживающий спецификацию, сценарии отслеживания будут по-прежнему присутствовать для очень большого процента пользователей.

Остальные предложения включают изменение содержимого iframe для удаления нарушающих скриптов.

Обратный прокси

Создание обратного прокси-сервера для блокировки нескольких сценариев отслеживания в iframe, вероятно, эквивалентно использованию ядерной боеголовки для освещения пожара в лагере до переполнения. Но, если вы в состоянии сконфигурировать свой сервер в такой степени, это самый надежный и бесшовный метод для ввода/изменения/блокирования содержимого iframe, который я нашел.

На странице Wikipedia указано:

Обратный прокси - это тип прокси-сервера, который извлекает ресурсы от имени клиента с одного или нескольких серверов. Эти ресурсы затем возвращаются клиенту, появляясь, как если бы они исходили от самого прокси-сервера.

Поскольку обратный прокси-сервер является посредником между сторонним приложением и вашим сайтом, он может прозрачно изменять ответы для удаления нежелательных сценариев. Я буду использовать Apache в этом примере, но ваша реализация действительно зависит от того, какой сервер вы уже используете.

Вам нужен субдомен для прокси-сервера, который указывает на ваш IP-адрес вашего сервера, например proxywebapp.yourdomain.com. На вашем сервере вы создадите виртуальный хост в httpd.conf, который использует модуль Apache mod_proxy. В вашей конфигурации виртуального хоста вы затем замените вызовы скриптов на AnalyticsJavaScript.com и TrackingPixel.com пробелами. Если стороннее приложение должно использовать HTTPS, тогда обратное проксирование становится более сложным, так как вам нужен виртуальный хост SSL и сертификат SSL для FQDN прокси.

<VirtualHost *:*>
    ServerName        proxywebapp.yourdomain.com
    ProxyPreserveHost On
    ProxyPass         "/" "http://app.thirdparty.com/"
    ProxyPassReverse  "/" "http://app.thirdparty.com"

    # in case any URLs have the original domain hard coded
    Substitute        "s|app.thirdparty.com/|proxywebapp.yourdomain.com/|i"
    # replace the undesired scripts with blanks
    Substitute        "s|AnalyticsJavaScript/| /|i"
    Substitute        "s|TrackingPixel/| /|i"
</VirtualHost>

Ваш iframe затем proxywebapp.yourdomain.com на proxywebapp.yourdomain.com.

<iframe ... src="proxywebapp.yourdomain.com" ...></iframe>

Опять же: полный перебор, но должен работать прозрачно.

Сценарии прокси-сервера

Третьим вариантом является внедрение прокси-скрипта на вашем сервере между iframe и сторонним приложением. Вы добавили бы функциональность в прокси-скрипт, который ищет и удаляет нежелательные сценарии, прежде чем они достигнут iframe. Кроме того, прокси означает, что содержимое iframe будет проверять политику одного и того же происхождения, поэтому вместо этого вы можете удалить нежелательный контент с помощью JavaScript в интерфейсе, хотя это может не гарантировать, что сценарии не будут выполняться до их удаления. Существует множество прокси-скриптов, доступных онлайн для всех видов бэкэндов (PHP, Node.js и т.д. Ad nauseum). Вероятно, вы установили бы скрипт и добавили его как iframe src, что-то вроде <iframe... src="proxy.php?https://app.thirdparty.com/"...>.

Если не настроен должным образом для всех случаев, прокси-сервер может неправильно передавать данные между сторонним приложением и его родительским сервером. Тестирование будет необходимо.

Написание собственного прокси-сервера на стороне сервера для удаления нескольких скриптов из iframe, вероятно, немного чрезмерно.

Если вы не можете получить доступ к бэкэнд, можно очистить содержимое веб-приложения с помощью JavaScript и веб-приложения CORS или JSONP и изменить его для удаления скриптов. По существу, создание собственного прокси-сервера в JavaScript. Такие веб-приложения (Any Origin, All Origins и т.д.) Позволяют обойти ограничения по междоменной политике, но поскольку они являются третьей стороной, вы больше не можете считать, что данные веб-приложения являются конфиденциальными. Проблема с правильной передачей любой передачи данных между приложением и его родительским сервером будет по-прежнему присутствовать.

Резюме

В настоящее время широко распространенное решение с открытым интерфейсом не представляется возможным. Но есть много способов скинуть кошку и, возможно, еще больше способов изменить содержимое iframe, независимо от междоменных ограничений.

Политика безопасности контента выглядит многообещающей и именно то, о чем вы просите, но в настоящее время ее отсутствие широко распространенной поддержки означает, что ее можно использовать только в очень нишевых ситуациях. Обратный прокси-сервер, который модифицирует контент, может занять много места, и в этой ситуации это похоже на вождение полноразмерного полуприцепа по дорожке Hot Wheels, но, скорее всего, будет работать без проблем. Модификация контента от прямого прокси-сервера несколько проще реализовать, но может нарушить связь с родительским сервером сторонних приложений.

Ответ 2

Вы не можете сделать это так, как хотите (на данный момент). Как упоминалось в комментариях CSP: EE еще впереди.

Однако вы можете попробовать проксировать запрос и удалить ненужные сценарии из тела на стороне сервера или на стороне клиента, например:

1) Получить необходимую страницу через XMLHTTPRequest

2) Удалить нежелательные

3) Вставить в iframe на странице

"Работоспособность" этого метода зависит исключительно от функциональности внешнего приложения. Т.е. это не сработает, если вышеупомянутое приложение нуждается в регистрации/авторизации конечного пользователя для работы, однако это может по-прежнему быть подходящим для некоторых простых случаев.

PS: вы можете реализовать обходное решение, чтобы сделать такую работу через расширение браузера, однако я уверен, что это не то, что вы хотите.