Web Proxy Autodiscovery Protocol

El Web Proxy Autodiscovery Protocol (WPAD) (en inglés Protocolo de autodescubrimiento de Proxy Web) es un método utilizado por clientes para encontrar la URL de un archivo de configuración utilizando métodos de descubrimiento de DHCP y/o DNS. Una vez que la detección y descarga del archivo de configuración se ha completado, puede ser ejecutado para determinar el proxy para un URL especificado.

Historia

El protocolo WPAD solo perfila el mecanismo para descubrir la ubicación de este archivo, pero el formato de archivo de configuración más comúnmente desplegado es el formato proxy auto-config originalmente diseñado por Netscape en 1996 para el Netscape Navigator 2.0.^[1]​ El protocolo WPAD fue redactado por un consorcio de compañías que incluyen Inktomi Corp, Microsoft, RealNetworks Inc., y Sun Microsystems, Inc. (ahora Oracle Corp.). WPAD está documentado en un borrador de INTERNET el cual expiró en diciembre de 1999.^[2]​ Aun así, WPAD es todavía aceptado por todos los navegadores importantes.^[3]​^[4]​ WPAD fue incluido por primera vez con Internet Explorer 5.0.

Contexto

Para que a todos los navegadores en una organización se les suministre la misma política de proxy, sin tener que configurar cada navegador manualmente, se requiere una de las dos tecnologías de más abajo:

• Estándar Proxy auto-config (PAC): crear y publicar un archivo de configuración de proxy central. Los detalles se discuten en un artículo separado.
• Estándar Web Proxy Autodiscovery Protocol (WPAD): asegura que los navegadores de una organización encontrarán este archivo sin configuración manual. Esto es el tema de este artículo.

El estándar WPAD define dos métodos alternativos para que el administrador de sistema puede usar para publicar la ubicación del archivo de configuración de proxy, usando el Dynamic Host Configuration Protocol (DHCP) o el Domain Name System (DNS):

Antes de que recupere su primera página, un navegador de web que implementa este método envía al servidor local DHCP una consulta DHCPINFORM, y utiliza el URL de la opción WPAD en la respuesta del servidor. Si el servidor DHCP no proporciona la información deseada, se usa DNS. Si, por ejemplo, el nombre de red del ordenador del usuario es pc.department.branch.example.com, el navegador probará las siguientes URLs en orden hasta que encuentre un archivo de configuración proxy dentro del dominio del cliente:

• 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 (en implementaciones incorrectas, véase nota en Seguridad abajo)

(Nota: Estos son ejemplos y no son URL "vivas" debido a que usan el nombre de dominio reservado de "example.com".)

Además en Windows si la consulta DNS no es exitosa entonces se usará Resolución de Nombre de Enlace-Local Multicast (LLMNR) será utilizado.

Además en Windows si la consulta DNS no es exitosa entonces se utilizará NetBios.^[5]​^[6]​

Notas

DHCP tiene una prioridad más alta que DNS: si DHCP proporciona el WPAD URL, no se ejecuta ninguna búsqueda DNS. Esto solo funciona con DHCPv4. En DHCPv6, no está definida la opción WPAD.

Notar que Firefox no permite usar DHCP, solo DNS, y lo mismo es cierto para Chrome en plataformas no Windows y para versiones de Chrome anteriores a la 13.^[3]​^[4]​

Cuándo construyen el paquete de consulta, la búsqueda DNS remueve a la primera parte del nombre de dominio (el nombre de host del cliente) y lo reemplaza con wpad. Entonces, se "mueve hacia arriba" en la jerarquía sacando más partes del nombre de dominio, hasta que encuentra un archivo WPAD PAC o deja la organización actual.

El navegador adivina donde están las fronteras de organización. La suposición es a menudo correcta para dominios como 'company.com' o 'university.edu', pero incorrectos para 'company.co.uk' (ver seguridad abajo).

Para las búsquedas DNS, el camino del archivo de configuración es siempre wpad.dat. Para el protocolo DHCP, cualquier URL es utilizable. Para razones tradicionales, los archivos PAC son a menudo llamados proxy.pac (naturalmente, los archivos con este nombre serán ignorados por la búsqueda DNS WPAD).

El tipo MIME del archivo de configuración tiene que ser "aplicación/x-ns-proxy-autoconfig". Ver Proxy auto-config para más detalles.

Internet Explorer y Konqueror son actualmente los únicos navegadores que ofrecen soporte para ambos métodos DHCP y DNS; el método DNS es permitido en los navegadores más importantes.^[7]​ ^[8]​

Requisitos

Para que WPAD para trabajar, deben cumplirse algunos requisitos:

• Para usar DHCP, el servidor tiene que ser configurado para entregar la opción "site-local" 252 ("auto-proxy-config") con un valor de texto de "http://example.com/wpad.dat" (sin las comillas) dónde "example.com" es la dirección de un servidor de Web (ya sea una dirección IP en formato números separados por puntos o un nombre DNS).
• Para utilizar solo el método DNS, una entrada DNS se necesita para un host llamado WPAD.
• El equipo en la dirección WPAD tiene que ser capaz de entregar una Página web.
• En ambos casos, el servidor web tiene que ser configurado para servir el archivo WPAD con un tipo MIME de "application/x-ns-proxy-autoconfig".
• Si se usa el método DNS, un archivo llamado wpad.dat tiene que ser puesto en el directorio raíz del sitio web WPAD.
• Los archivos PAC se discuten en el artículo Proxy auto-config.
• Tenga cuidado al configurar un servidor WPAD en un ambiente de hosting virtual. Cuando la detección automática de proxy se utilice, WinHTTP y WinINET en Internet Explorer 6 y anteriores enviarán un encabezado "Host: <dirección IP>" y IE7+ y Firefox enviarán un encabezado "Host: wpad". Por lo tanto, se recomienda que el archivo wpad.dat sea alojado bajo el host virtual por omisión antes que en el suyo propio.
• La versión del Internet Explorer 6.0.2900.2180.xpsp_sp2_rtm requiere "wpad.da" en vez de "wpad.dat" del servidor web.
• Si estás utilizando Windows Server 2003 (o posterior) como servidor DNS, podrías tener que deshabilitar la Lista Global de Bloqueo de Consulta del Servidor DNS, o incluso modificar el registro para editar la lista de bloqueó consultas.^[9]​^[10]​

Seguridad

Así como simplifica mucho la configuración de los navegadores web de una organización, el protocolo WPAD tiene que ser utilizado con cuidado: equivocaciones sencillas pueden abrir puertas para que atacantes cambien lo que aparece en el navegador de un usuario:

• Un atacante dentro de una red puede instalar un servidor DHCP que entregue el URL de un archivo PAC malicioso.
• Si la red es 'company.co.uk' y el archivo http://wpad.company.co.uk/wpad.dat (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última). no es provisto, los navegadores irán luego a pedir . El navegador no determina si esto está todavía dentro de la organización. Ver http://wpad.com/ para un ejemplo.
• El mismo método ha sido utilizado con http://wpad.org.uk (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última).. Esto fue utilizado para entregar un archivo wpad.dat que redirigiría todo del tráfico del usuario a un sitio de subasta en internet.^{[cita requerida]}
• Algunos ISPs que han implementado DNS hijacking pueden romper la búsqueda DNS del protocolo WPAD al dirigir a los usuarios a un host que no es un servidor proxy.
• Consultas WPAD filtradas podrían resultar en colisiones de nombre del dominio con esquemas de nombres de la red interna. Si un atacante registra un dominio para contestar consultas WPAD filtradas y configura un proxy válido, está el potencial de conducir ataques man-in-the-middle (MitM) a través del Internet.^[11]​

A través del archivo WPAD, el atacante puede apuntar los navegadores de los usuarios a su propios proxies e interceptar y modificar todo el tráfico WWW. A pesar de que se aplicó un parche simple al manejo de WPAD en Windows en 2005, este solo corrige el problema para el dominio .com.^[12]​ Una presentación en Kiwicon mostró que el resto del mundo era todavía críticamente vulnerable a este agujero de seguridad, con un dominio de ejemplo registrado en Nueva Zelanda para propósitos de probar las solicitudes de proxy que reciben de todas partes del país a una tasa de varios por segundo. Muchos dominios wpad.tld (incluyendo COM, NET, ORG y US) ahora apuntan a la dirección de loopback del cliente para ayudar a proteger contra esta vulnerabilidad, aunque algunos nombres todavía están registrados (wpad.co.uk).^{[cita requerida]}

Así, un administrador tendría que asegurarse que un usuario puede confiar en cualquier servidor DHCP en una organización y que todos los posibles dominios wpad para la organización están bajo control. Aún má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 va a usar como su configuración. Esto deja a quienquiera que registre el subdominio wpad en un país particular en condiciones de hacer un ataque man-in-the-middle en grandes porciones del tráfico de internet de aquel país al ponerse ellos como proxy para todo tráfico o sitios de interés.^[13]​

Además de estas trampas, el método WPAD busca un archivo de Javascript^[14]​ y lo ejecuta en todos navegadores de los usuarios, incluso cuándo han inutilizado Javascript para ver páginas web.

Referencias

1. . Netscape Navigator Documentation. March 1996. Archivado desde el original el 7 de marzo de 2007. Consultado el 10 de febrero de 2015. 
2. Gauthier, Paul; Josh Cohen; Martin Dunsmuir; Charles Perkins (28 de julio de 1999). «Web Proxy Auto-Discovery Protocol (INTERNET-DRAFT)». IETF. Consultado el 10 de febrero de 2015. 
3. «Chromium #18575: Non-Windows platforms: WPAD (proxy autodetect discovery) does not test DHCP». 5 de agosto de 2009. Consultado el 10 de febrero de 2015. 
4. «Firefox #356831 - Proxy autodiscovery doesn't check DHCP (option 252». 16 de octubre de 2006. Consultado el 10 de febrero de 2015. 
5. . GFI Software. Archivado desde el original el 14 de abril de 2021. Consultado el 10 de febrero de 2015. 
6. Hjelmvik, Erik (17 de julio de 2012). «WPAD Man in the Middle». Consultado el 10 de febrero de 2015. 
7. . KDE. 20 de mayo de 2013. Archivado desde el original el 11 de febrero de 2015. Consultado el 10 de febrero de 2015. 
8. «Konqueror: Automatic ¡favicon». KDE. 20 de mayo de 2017. Consultado el 10 de febrero de 2017. 
9. King, Michael (17 de febrero de 2010). «WPAD does not resolve in DNS». Consultado el 10 de febrero de 2015. 
10. «Removing WPAD from DNS block list». Microsoft TechNet. Consultado el 10 de febrero de 2015. 
11. US-CERT (1 de junio de 2016). «Alert (TA16-144A) WPAD Name Collision Vulnerability» (en inglés). Consultado el 15 de junio de 2016. 
12. Fontana, John (26 de noviembre de 2007). «Microsoft working to close 8-year-old Web proxy vulnerability». Network World (en inglés). Consultado el 15 de junio de 2016. 
13. Constantin, Lucian (26 de mayo de 2016). «Top-level domain expansion is a security risk for business computers». PC World NZ (en inglés). Consultado el 15 de junio de 2016. 
14. Pashley, David. «Automatic Proxy Configuration with WPAD» (en inglés). Consultado el 15 de junio de 2016. 

Lectura adicional

• Jonathan de Boyne Pollard (2004). . Frequently Given Answers. Archivado desde el original el 3 de junio de 2013. (en inglés)

• Jim Groves (Noviembre de 2007). «DNS Server Global Query Block List». (en inglés)

• «PAC File & WPAD Examples». 18 de septiembre de 2015. (en inglés)

•   Datos: Q1747573