Плагин Firefox или Chrome для блокировки и фильтрации всех исходящих соединений - PullRequest
3 голосов
/ 29 апреля 2011

В Firefox или Chrome я бы хотел запретить частной веб-странице устанавливать исходящие соединения, т. Е. Если URL-адрес начинается с http://myprivatewebpage/ или https://myprivatewebpage/ на вкладке браузера, то на этой вкладке браузера должно быть ограничено, чтобы можно было загружать изображения, CSS, шрифты, JavaScript, XmlHttpRequest, Java-апплеты, флэш-анимацию и все другие ресурсы только из 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.log Google ps_logo.png, поэтому веб-мастера Google имели бы некоторую информацию о том, как myprivatewebpage используется, и я не хочу этого. (В этом вопросе меня не интересует, является ли ограничение разумным, но меня интересуют только технические решения, его сильные и слабые стороны.)

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

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

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

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

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

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

  • Найдите или напишите расширение 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:

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

1 Ответ

1 голос
/ 26 января 2012

Я нашел 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 Запрещено. Таким образом:
  6. Когда пользователь посещает любую веб-страницу, которая находится в myprivatewebpage, это нормальное поведение.
  7. Когда пользователь посещает любую веб-страницу за пределами myprivatewebpage, доступ запрещается.

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

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

...