Web Proxy Autodiscovery Protocol

Материал из Википедии — свободной энциклопедии
Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 5 октября 2020 года; проверки требуют 13 правок.
Перейти к навигации Перейти к поиску

Web Proxy Auto-Discovery Protocol (WPAD) (протокол автоматической настройки прокси) — метод, используемый клиентами для определения места (URL) расположения конфигурационного файла с использованием технологий DHCP и/или DNS. После того, как определено местоположение файла конфигурации и сам файл получен, клиент использует его для определения, каким прокси воспользоваться для каждого конкретного URL. Протокол WPAD только определяет механизм поиска файла конфигурации, а вместе с ним чаще всего используется формат конфигурационного файла, разработанный фирмой Netscape в 1996 для Netscape Navigator 2.0.[1] Впервые протокол WPAD был описан консорциумом компаний Inktomi Corporation, Microsoft Corporation, RealNetworks, Inc., и Sun Microsystems, Inc.. Позже протокол WPAD был официально задокументирован в INTERNET-DRAFT, действие которого закончилось в декабре 1999.[2] Протокол WPAD поддерживается только старшими версиями браузеров. А впервые он был использован в Internet Explorer 5.0.

Описание

[править | править код]

Для того, чтобы все браузеры в организации могли быть настроены без ручного конфигурирования каждого браузера, необходимо, чтобы работали две нижеперечисленные технологии:

  • стандарт Proxy auto-config[англ.] (PAC): необходимо создать и сделать доступным файл конфигурации. Различные детали этого описаны в разных статьях;
  • стандарт Web Proxy Autodiscovery Protocol (WPAD): необходимо убедиться, что все браузеры в организации могут найти этот файл без указания его местонахождения вручную. Данная статья описывает этот процесс.

WPAD-стандарт описывает два альтернативных метода распространения информации о расположении файла конфигурации для системных администраторов с использованием Dynamic Host Configuration Protocol (DHCP) или Domain Name System (DNS).

До того, как будет загружена первая страница, браузер использует эту технологию для отправки локальному DHCP-серверу DHCPINFORM-запроса и использует полученный URL из WPAD-опции ответа сервера. Если DHCP-сервер не может предоставить требуемую информацию, то используется DNS. Если, например, DNS-имя компьютера pc.department.branch.example.com, браузер попытается обратиться к следующим URL для поиска конфигурационного файла:

  • http://wpad.department.branch.example.com/wpad.dat
  • http://wpad.branch.example.com/wpad.dat
  • http://wpad.example.com/wpad.dat
  • http://wpad.com/wpad.dat (обратите внимание на заметку о безопасности)

(Это только примеры URL)

Заметки

[править | править код]
  • DHCP более приоритетен, чем DNS: если DHCP предоставляет WPAD URL, DNS не используется. Firefox не использует DHCP, только DNS.
  • В DNS-запросе отбрасывается первая часть доменного имени (описывающая клиентское имя) и заменяется на wpad. Затем происходит «движение вверх» в иерархии доменных имён, пока не будет найден адрес расположения конфигурационного файла или не будет покинут домен организации.
  • Браузер пытается определить домен организации и пытается подставить названия доменов вида 'company.com' или 'university.edu', но не 'company.co.uk' (обратите внимание на заметку о безопасности).
  • При DNS-запросе предполагается, что именем файла конфигурации всегда является wpad.dat. При использовании DHCP-протокола может использоваться любой корректный URL. Исторически сложилось, что PAC-файл обычно называется proxy.pac (конечно же, при использовании DNS-способа это имя игнорируется).
  • MIME type файла конфигурации должен быть именно «application/x-ns-proxy-autoconfig». Пожалуйста, прочтите Proxy auto-config для уточнения деталей.
  • Сейчас только Internet Explorer и Konqueror поддерживают оба метода (DHCP и DNS), DNS-метод поддерживается большинством современных браузеров.

Требования

[править | править код]

Для того, чтобы WPAD работал, должны быть выполнены следующие условия:

  • При использовании DHCP необходимо, чтобы сервер предоставлял «site-local» опцию 252 («auto-proxy-config») со строковым значением вида «http://xxx.yyy.zzz.qqq/wpad.dat» (без кавычек, конечно), где xxx.yyy.zzz.qqq — адрес веб-сервера(в любом виде: IP или DNS).
  • При использовании DNS необходима запись об имени хоста WPAD.
  • Хост WPAD должен уметь выдавать веб-страницы.
  • В обоих случаях веб-сервер должен быть сконфигурирован таким образом, чтобы выдавать dat-файлы с MIME type «application/x-ns-proxy-autoconfig».
  • Файл с названием wpad.dat должен располагаться на хосте WPAD в root directory.
  • Пример PAC-файла можно посмотреть в Proxy auto-config.
  • Будьте аккуратны при конфигурировании WPAD-сервера virtual hosting окружении. Когда происходит автоматическое определение прокси, Internet Explorer отправляет заголовок вида «Host: <IP address>», а Firefox отправляет заголовок «Host: wpad». Всё это может привести к непредсказуемому поведению сервера, поэтому рекомендуется, чтобы файл wpad.dat располагался в default Virtual Host.
  • Internet Explorer версии 6.0.2900.2180.xpsp_sp2_rtm запрашивает у веб-сервера «wpad.da» вместо «wpad.dat».
  • Начиная с Windows 2008 и в последующих обновлений безопасности «MS09-008 for Windows Server 2003 DNS and WINS servers» используется технология Global query block list Архивная копия от 1 июля 2015 на Wayback Machine . Принудительно запрещается разрешать адреса WPAD, ISATAP в DNS в целях противодействия атакам на подмену серверу WPAD.

Безопасность

[править | править код]

Вместе с возможностью очень легко сразу сконфигурировать все браузеры в организации, WPAD-протокол должен использоваться очень аккуратно — простые ошибки могут открыть дверь атакующим для внесения изменений через пользовательские браузеры:

  • Атакующий внутри сети может запустить DHCP-сервер, который будет предлагать поддельный PAC-скрипт.
  • Если домен организации 'company.co.uk', а файл http://wpad.company.co.uk/wpad.dat не существует, то браузеры попытаются обратиться к http://wpad.co.uk/wpad.dat. Браузер не может сам определить, когда он покидает домен организации. Наглядный пример — http://wpad.com/ Архивная копия от 19 июля 2006 на Wayback Machine
  • То же самое относится и к http://wpad.org.uk. Например, при использовании файла wpad.dat с подобного сайта, можно перенаправить весь пользовательский трафик на сайт интернет-аукциона.
  • ISP, которые используют технологии DNS hijacking, могут пресечь DNS-запрос по WPAD-протоколу, перенаправив пользователей к сайту, который не является прокси.

Посредством WPAD-файла атакующий может перенаправить пользовательские браузеры на свой собственный прокси, вклиниться в передачу и модифицировать весь www-трафик. Несмотря на внесение простейшего изменения для Windows в управлении WPAD в 2005 году, оно только защищает от проблем с использованием домена .com. Сюжет-презентация Kiwicon показывает, чем может обернуться беспечность в отношении даже маленькой уязвимости, когда для тестов был зарегистрирован простой домен в Новой Зеландии и к нему в течение нескольких секунд начали поступать прокси-запросы изо всех стран мира.

Конечно же, администратор должен быть уверен, что пользователи могут доверять всем DHCP-серверам в организации и что все возможные WPAD-домены для организации под контролем.

Более того, если wpad-домен не сконфигурирован для организации, то пользователи могут дойти до какого-нибудь внешнего, следующего wpad-домена и использовать его для самоконфигурирования. Регистрация такого поддомена в конкретной стране позволит осуществлять атаки вида man-in-the-middle («человек посередине») над громадной долей интернет-трафика всей страны, если дополнительно установить прокси-сервер и заворачивать весь трафик на него.

И в завершение нужно упомянуть, что WPAD-метод фактически ищет и скачивает файл JavaScript, после чего выполняет его в браузере, где, однако, JavaScript уже может быть отключён в настройках.

Примечания

[править | править код]
  1. ↑ Navigator Proxy Auto-Config File Format. Netscape Navigator Documentation (март 1996). Дата обращения: 29 сентября 2009. Архивировано 18 декабря 2006 года.
  2. ↑ Gauthier, Paul; Josh Cohen, Martin Dunsmuir, Charles Perkins.: INTERNET-DRAFT Web Proxy Auto-Discovery Protocol. IETF (28 июля 1999). Дата обращения: 15 октября 2009. Архивировано 23 апреля 2012 года.

Ссылки

[править | править код]
Источник — https://ru.wikipedia.org/w/index.php?title=Web_Proxy_Autodiscovery_Protocol&oldid=134285618