El protocolo de detección automática de proxy web (WPAD) es un método que utilizan los clientes para localizar la URL de un archivo de configuración mediante métodos de detección de DHCP o DNS . Una vez que se completa la detección y descarga del archivo de configuración, se puede ejecutar para determinar el proxy para una URL específica.
El protocolo WPAD sólo describe el mecanismo para descubrir la ubicación de este archivo, pero el formato de archivo de configuración más comúnmente implementado es el formato de configuración automática de proxy diseñado originalmente por Netscape en 1996 para Netscape Navigator 2.0 . [1] El protocolo WPAD fue redactado por un consorcio de empresas que incluía a Inktomi Corporation , Microsoft Corporation , RealNetworks, Inc. y Sun Microsystems, Inc. (ahora Oracle Corp. ). WPAD está documentado en un BORRADOR DE INTERNET que expiró en diciembre de 1999. [2] Sin embargo, WPAD todavía es compatible con todos los navegadores principales. [3] [4] WPAD se incluyó por primera vez con Internet Explorer 5.0 .
Para que todos los navegadores de una organización reciban la misma política de proxy, sin configurar cada navegador manualmente, se requieren las dos tecnologías siguientes:
El estándar WPAD define dos métodos alternativos que el administrador del sistema puede utilizar para publicar la ubicación del archivo de configuración del proxy, utilizando el Protocolo de configuración dinámica de host (DHCP) o el Sistema de nombres de dominio (DNS):
Antes de obtener su primera página, un navegador web que implementa este método envía una consulta DHCPINFORM al servidor DHCP local y utiliza la URL de la opción WPAD en la respuesta del servidor. Si el servidor DHCP no proporciona la información deseada, se utiliza DNS. Si, por ejemplo, el nombre de red de la computadora del usuario es pc.department.branch.example.com , el navegador probará las siguientes URL una por una hasta que encuentre un archivo de configuración de proxy dentro del dominio del cliente:
(Nota: Estos son ejemplos y no son URL "en vivo" debido a que emplean el nombre de dominio reservado de " ejemplo.com ").
Además, en Windows, si la consulta DNS no tiene éxito, se utilizará la resolución de nombres de multidifusión local de enlace (LLMNR) y/o NetBIOS . [5] [6]
DHCP tiene mayor prioridad que DNS: si DHCP proporciona la URL de WPAD, no se realiza ninguna búsqueda de DNS. Esto solo funciona con DHCPv4. En DHCPv6, no hay una opción WPAD definida.
Al construir el paquete de consulta, la búsqueda DNS elimina la primera parte del nombre de dominio (el nombre de host del cliente) y lo reemplaza por wpad . Luego, "asciende" en la jerarquía eliminando más partes del nombre de dominio, hasta que encuentra un archivo PAC de WPAD o abandona la organización actual.
El navegador adivina dónde están los límites de la organización. La suposición suele ser correcta para dominios como "company.com" o "university.edu", pero incorrecta para "company.co.uk" (consulte la sección de seguridad a continuación).
Para las búsquedas DNS, la ruta del archivo de configuración siempre es wpad.dat . Para el protocolo DHCP, se puede utilizar cualquier URL. Por razones tradicionales, los archivos PAC suelen llamarse proxy.pac (por supuesto, la búsqueda DNS de WPAD ignorará los archivos con este nombre).
El tipo MIME del archivo de configuración debe ser "application/x-ns-proxy-autoconfig". Consulte Configuración automática del proxy para obtener más detalles.
Internet Explorer y Konqueror son actualmente los únicos navegadores que ofrecen soporte para los métodos DHCP y DNS; el método DNS es compatible con la mayoría de los navegadores principales. [7]
Para que WPAD funcione, se deben cumplir algunos requisitos:
application/x-ns-proxy-autoconfig.Si bien el protocolo WPAD simplifica enormemente la configuración de los navegadores web de una organización, debe usarse con cuidado: errores simples pueden abrir puertas para que los atacantes cambien lo que aparece en el navegador de un usuario:
A través del archivo WPAD, el atacante puede dirigir los navegadores de los usuarios a sus propios servidores proxy e interceptar y modificar el tráfico WWW de todos los usuarios conectados a la red. Aunque en 2005 se aplicó una solución simplista para el manejo de WPAD en Windows, sólo se solucionó el problema del dominio .com. Una presentación en Kiwicon mostró que el resto del mundo seguía siendo críticamente vulnerable a este agujero de seguridad, con un dominio de muestra registrado en Nueva Zelanda con fines de prueba que recibía solicitudes de proxy de todo el país a una velocidad de varias por segundo. Varios de los nombres de dominio wpad.tld (incluidos COM, NET, ORG y US) ahora apuntan a la dirección de bucle invertido del cliente para ayudar a protegerse contra esta vulnerabilidad, aunque algunos nombres aún están registrados (wpad.co.uk).
Por lo tanto, un administrador debe asegurarse de que un usuario pueda confiar en todos los servidores DHCP de una organización y de que todos los posibles dominios wpad de la organización estén bajo control. Además, si no hay un dominio wpad configurado para una organización, un usuario irá a cualquier ubicación externa que tenga el siguiente sitio wpad en la jerarquía de dominios y lo usará para su configuración. Esto permite que quien registre el subdominio wpad en un país en particular realice un ataque de intermediario en grandes porciones del tráfico de Internet de ese país al configurarse como un proxy para todo el tráfico o los sitios de interés.
Además de estas trampas, el método WPAD obtiene un archivo JavaScript y lo ejecuta en los navegadores de todos los usuarios, incluso cuando han desactivado JavaScript para ver páginas web.