Блог

В Firefox или Chrome я хотел бы запретить частной веб-странице устанавливать исходящие подключения, т. Е. если URL-адрес начинается сhttp://myprivatewebpage / или https://myprivatewebpage на вкладке браузера эта вкладка браузера должна быть ограничена, чтобы разрешалось загружать изображения, CSS, шрифты, JavaScript, XMLHttpRequest, Java-апплеты, flash-анимацию и все другие ресурсы только из http://myprivatewebpage / или https://myprivatewebpage /, т.е. <img src="http://www.google.com/images/logos/ps_logo.png"> (или соответствующий <script>new Image(...) ) не должен иметь возможности загружать это изображение, поскольку его нет на myprivatewebpage. Мне нужно 100% и надежное решение: ни один ресурс за пределами myprivatewebpage не может быть доступен, даже с низкой вероятностью. Не должно быть ограничений на загрузку ресурсов на веб-страницах, отличных от myprivatewebpage, например http://otherwebpage / должен иметь возможность загружать изображения из google.com.

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

Причина, по которой мне нужно это ограничение, заключается в том, чтобы сохранить myprivatewebpage действительно приватной, не предоставляя никакой информации о ее использовании веб-мастерам других веб-страниц. Если http://www.google.com/images/logos/ps_logo.png был разрешен, тогда использование myprivatewebpage регистрировалось бы в access.журнал Google ps_logo.png , чтобы веб-мастера Google имели некоторую информацию о том, как используется myprivatewebpage, а я этого не хочу. (В этом вопросе меня не интересует, является ли ограничение разумным, но меня интересуют только технические решения и их сильные и слабые стороны.)

Мои идеи, как реализовать ограничение:

• Не накладывайте никаких ограничений, просто полагайтесь на ту же политику origin. (Это не обеспечивает необходимой защиты, та же политика origin позволяет передавать все изображения.)

• Измените веб-приложение на сервере, чтобы оно генерировало HTML, JavaScript, Java-апплеты, flash-анимацию и т.д. который никогда не пытается загрузить что-либо за пределами myprivatewebpage. (Практически невозможно обеспечить надежную защиту в любом сложном веб-приложении, особенно с пользовательским контентом.)

• Чрезмерно очистите веб-страницу с помощью фильтра вывода HTML на сервере, т.е. удалите все теги <script> , <embed> и <object> <img src= , ограничьте цель <link rel= , <form action= ,,, и т.д., А также ограничьте ссылки в файлах CSS. (Это может предотвратить все нежелательные ресурсы, если я могу правильно запомнить все HTML-теги, например, я не должен забывать о <video> . Но это слишком ограничительно: оно удаляет все функциональные возможности динамической веб-страницы, такие как JavaScript, Java-апплеты и flash-анимации; без них большинство веб-приложений бесполезны.)

• Очистите веб-страницу, т.е. добавьте на веб-сервер фильтр вывода HTML, который удаляет все оскорбительные URL-адреса из сгенерированного HTML. (Это ненадежно, потому что может быть сложный JavaScript, который генерирует запрещенный URL. Он также не защищает от URL-адресов, загружаемых Java-апплетами и flash-анимациями.)

• Установите HTTP-прокси, который блокирует запросы на основе URL и HTTP-ссылки, и принудительно используйте весь трафик браузера (включая myprivatewebpage, otherwebpage, google.com ) через этот HTTP-прокси. (Это замедлило бы трафик, направленный не на myprivatewebpage, и, возможно, он не защищает должным образом, если XMLHttpRequest () ы, Java-апплеты или flash-анимации могут подделать HTTP-реферер.)

• Найдите или напишите расширение Firefox или Chrome, которое перехватывает все исходящие подключения и блокирует их на основе URL вкладки и целевого URL соединения. Я нашел https://developer.mozilla.org/en/Setting_HTTP_request_headers и thinkahead.js в https://addons.mozilla.org/en-US/firefox/addon/thinkahead / и http://thinkahead.mozdev.org / . Правильно ли я понимаю, что с его помощью можно написать расширение для Firefox? Есть ли такое расширение для Firefox уже?

Я нашел несколько ссылок для расширения Chrome:

• http://www.chromium.org/developers/design-documents/extensions/notifications-of-web-request-and-navigation
• https://groups.google.com/a/chromium.org/group/chromium-extensions/browse_thread/thread/90645ce11e1b3d86?pli=1
• http://code.google.com/chrome/extensions/trunk/experimental.webRequest.html

Насколько я вижу, из приведенного выше списка доступно только расширение Firefox или Chrome. У вас есть какие-либо другие предложения? У вас есть какие-нибудь указания, как написать или где найти такое расширение?

Я нашел https://developer.mozilla.org/en/Setting_HTTP_request_headers и thinkahead.js в https://addons.mozilla.org/en-US/firefox/addon/thinkahead / и http://thinkahead.mozdev.org / . Правильно ли я понимаю, что с его помощью можно написать расширение для Firefox? Есть ли такое расширение для Firefox уже?

Я являюсь автором последнего расширения, хотя мне еще предстоит обновить его для поддержки более новых версий Firefox. Мое первоначальное предположение заключается в том, что да, он будет делать то, что вы хотите:

1. Пользователь посещает вашу веб-страницу без плагина. Веб-страница содержит блок ThinkAhead, который отправил бы простой заголовок версии на сервер, но это игнорируется, поскольку плагин не установлен.
2. Поскольку сервер не видит этот заголовок, он перенаправляет клиента на страницу для установки плагина.
3. Пользователь устанавливает плагин.
4. Пользователь посещает веб-страницу с помощью плагина. Страница отправляет заголовок версии на сервер, поэтому сервер разрешает доступ.
5. Блок ThinkAhead сопоставляет все страницы, которые не myprivatewebpage являются таковыми, и выполняет что-то вроде установки статуса HTTP на 403 Forbidden. Таким образом:
6. Когда пользователь посещает любую веб-страницу, которая находится в myprivatewebpage , это нормальное поведение.
7. Когда пользователь посещает любую веб-страницу за пределами myprivatewebpage , доступ запрещен.

Если вы хотите перехватывать неверные запросы раньше, вместо изменения входящих заголовков вы могли бы изменить исходящие заголовки, возможно, перепутав «If-Match» или «Accept», чтобы запрос никогда не выполнялся.

Это решение чрезвычайно легкое, но может оказаться недостаточно надежным для решения ваших проблем. Это зависит от того, что вы хотите защитить: учитывая вышесказанное, клиент не сможет видеть заблокированный контент, но внешние «заблокированные» хосты все равно могут заметить, что запрос был отправлен, и, возможно, смогут собирать информацию по URL-адресу запроса.