Una gran cantidad de proyectos web recurre a servidores proxy para mejorar el rendimiento y la seguridad. Estos prácticos programas funcionan como interfaces de comunicación entre el cliente y la página web y aligeran la carga del servidor web haciéndose cargo de solicitudes HTTP editándolas, reenviándolas y respondiendo a ellas. Debido a una brecha de seguridad conocida como HTTPoxy, puede que algunos atacantes abusen de esta técnica para robar datos. En ello se ven afectadas las aplicaciones que se basan en el estándar CGI (Common Gateway Interface) y que llevan consigo variables configurables, es decir, las llamadas variables de entorno. A partir de las variables correspondientes, algunos programas pueden leer la configuración del proxy, lo que representa un problema en caso de que los criminales manipulen dichos ajustes.
Cuando un servidor web se comunica vía Common Gateway Interface con el cliente de un usuario, el estándar 3875 prevé que los encabezados de todas las solicitudes HTTP enviadas se guarden como variables de entorno. Estas variables están formadas por el prefijo “HTTP_” y por el nombre del encabezado en mayúsculas. En el caso detallado, se trata del encabezado “Proxy”, que genera la variable HTTP_PROXY de manera automática. Esta se destina, por lo general, a la configuración de los ajustes del proxy. Si la aplicación CGI localiza o ejecuta una solicitud que comprende HTTP_PROXY, esta se desvía a través del servidor proxy.
Esta circunstancia permite que los atacantes pongan en juego su propio servidor proxy y, de esta manera, tengan acceso a información confidencial. Para lograrlo, el servidor envía una solicitud HTTP con el encabezado Proxy y un valor correspondiente (por ejemplo, la dirección IP del proxy), de modo que las peticiones futuras de los usuarios, ya sean entrantes o salientes, se desvíen hacia este. En función del escenario elegido, el atacante puede enviar de vuelta y a su antojo sus propios datos o leer en vía directa los datos que introduce el usuario.
La vulnerabilidad HTTPoxy, cuyo nombre no tiene un significado especial, llamó la atención por primera vez en marzo de 2001. El programador Randal L. Schwartz la descubrió en la biblioteca libwww-perl del lenguaje de programación Perl y así se lo transmitió a Gisle Aas, el desarrollador de dicha biblioteca. Este solucionó la brecha de seguridad inmediatamente en la actualización 5.51, mientras que los nombres de las variables a través de los que se controla la configuración del proxy se modificaron en CGI_HTTP_PROXY. Durante el mismo año también salió a la luz la vulnerabilidad en el programa de transferencia de datos curl, con lo que el desarrollador Daniel Stenberg adaptó el software, de modo que en lo sucesivo solo afectara a las variantes http_proxy escritas en minúscula para la determinación del servidor proxy —destacando al mismo tiempo que, en general, esto no es suficiente para los sistemas Microsoft, aunque las versiones actuales de Windows ya no presentarían este problema.
Alrededor de una década después, en julio de 2012, el equipo de Ruby se topó con la problemática HTTPoxy ya olvidada durante la implementación de la clase NET::HTTP, una API para los clientes HTTP diseñada para las aplicaciones hechas con Ruby. Para evitar el problema, se retira al HTTP_PROXY su estatus de variable estándar. En los años siguientes, las aplicaciones de servidor web NGINX (2013) y Apache (2015) formaron parte de los casos más famosos en los que los usuarios más perspicaces informaron a los desarrolladores de los posibles riesgos.
En 2016, el equipo de seguridad de la empresa de desarrolladores Vend puso de manifiesto que la vulnerabilidad HTTPoxy, aun 15 años después de que saliera a la luz, todavía constituía un riesgo para PHP y otros lenguajes de programación, así como en bibliotecas, siempre y cuando esta se usara en combinación con CGI o con un entorno en tiempo de ejecución equiparable con variables configurables. Muchas aplicaciones afectadas que permiten la utilización de HTTPoxy fueron clasificadas como especificaciones oficiales para las brechas de seguridad, lo que se conoce como CVE (Common Vulnerabilities and Exposures o, en español, exposiciones y vulnerabilidades comunes):
Independientemente de si gestionas un servidor web propio o no, HTTPoxy plantea riesgos desde el momento que te internas en la World Wide Web. En caso de que el servicio web visitado se desvíe de manera no deseada a través de solicitudes HTTP externas, la consecuencia puede ser que tus datos pasen a manos deshonestas. Para que disminuya el riesgo de pérdida de datos, es preferible optar por páginas web protegidas a través de un certificado TLS/SSL y transmitir información cifrada. En este sentido sigue siendo posible redireccionar los datos a través de un proxy falso, y es que los criminales obtienen muy pocos beneficios o, en el mejor de los casos, ninguno de estos datos protegidos. Para los gestores de las páginas web propias, es imprescindible hoy en día hacer uso del certificado HTTPS.
Sin embargo, siempre está la opción de evitar HTTPoxy simplemente eliminando la vulnerabilidad. Puesto que el encabezado Proxy no se aferra ni a un estándar de la IETF (Internet Engineering Task Force) ni está registrado como encabezado oficial en la IANA (Internet Assigned Numbers Authority), se puede interceptar sin ninguna objeción antes de que alcance a tu aplicación web. Los clientes HTTP estándares y los servidores no envían ningún paquete de datos que contenga dicho encabezado. En principio, además del cifrado del intercambio de datos en HTTP, puedes recurrir a dos posibilidades para que las solicitudes peligrosas se mantengan alejadas de tu proyecto web:
La primera variante está mucho más extendida que la segunda y puede llevarse a cabo con ayuda del software habitual para servidores web, servidores proxy y el balance de carga. A continuación te presentamos información sobre cómo se puede extraer el encabezado potencialmente peligroso con ayuda de aplicaciones de servidores web como Apache y NGINX o con el software de servidores proxy HAProxy en diferentes distribuciones Linux.
Por defecto, el software libre Apache está instalado en todas las distribuciones Linux y para muchos sigue siendo hasta ahora la primera opción cuando se trata de gestionar los servidores web propios. El componente esencial del programa es, entre otros, el módulo mod_headers, que permite filtrar el encabezado Proxy de todas las solicitudes HTTPS entrantes. El modus operandi revela algunas diferencias entre las distribuciones.
Ubuntu y Debian:
El primer paso consiste en activar el módulo con el siguiente comando:
sudo a2enmod headersAbre el archivo de configuración central de Apache con un editor. A este respecto se recomienda nano, la herramienta de líneas de comandos utilizada en el ejemplo:
sudo nano /etc/apache2/apache2.confAmplía este archivo con la siguiente entrada al final:
<IfModule mod_headers.c>
RequestHeader unset Proxy early
</IfModule>Tras haber guardado el archivo, activa la protección contra HTTPoxy cargando el archivo de configuración especificado mediante el script a2enconf y reinicia el servidor:
sudo a2enconf httpoxy
sudo service apache2 restartCentOS y Fedora:
Si utilizas una versión de las distribuciones de Linux CentOS o Fedora, el módulo mod_headers suele estar activado por defecto, por lo que puedes saltarte este paso y abrir directamente el archivo de configuración:
sudo nano /etc/httpd/conf/httpd.confAl final de este debes incluir la entrada nueva:
RequestHeader unset Proxy earlyPor último, guarda los cambios y reinicia el servidor Apache:
sudo service httpd restartNGINX es una consolidada aplicación de servidor web que goza de una popularidad cada vez mayor. Con ayuda del software open source solo se necesitan unos pasos para proteger las aplicaciones CGI que se ejecutan en el servidor o entre el cliente y el servidor de las brechas de seguridad conocidas como HTTPoxy.
Ubuntu y Debian:
Normalmente, los parámetros FastCGI (FastCGI es una optimización del estándar CGI) en Ubuntu y Debian están incluidos en los archivos fastcgi_params o fastcgi.conf cuando se configura un proxy FastCGI con NGINX. En ambos archivos se puede colocar el encabezado Proxy en las solicitudes HTTP. Utiliza para ello las siguientes líneas de comandos:
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi_paramsPodrás filtrar el encabezado siempre y cuando utilices NGINX como proxy HTTP convencional. Para ello, introduce la regla correspondiente en el archivo proxy_params, en el que se especifican los parámetros para el servidor proxy:
echo 'proxy_set_header Proxy "";' | sudo tee -a /etc/nginx/proxy_paramsPor último, se reinicia NGINX con el siguiente comando:
sudo service nginx restartCentOS y Fedora:
El procedimiento para eliminar el peligro del HTTPoxy para los proxys FastCGI, que se pueden gestionar con CentOS o Fedora, no se diferencia del método necesario para los sistemas Ubuntu y Debian. Puesto que los ajustes en NGINX también se definen para estas distribuciones o en el archivo fastcgi_params o en fastcgi.conf, elimina el encabezado Proxy con el comando previamente definido:
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi_paramsPara proteger proxys inusuales en Fedora y CentOS, hay que garantizar que el encabezado está bloqueado en todos aquellos lugares en los que NGINX ejecuta la directiva proxy_pass. Para averiguar dónde se puede aplicar, se puede recurrir a los servicios del comando grep:
sudo grep -r "proxy_pass" /etc/nginxA continuación, recibirás una lista de los archivos de texto en los que se tiene que ejecutar la directiva, donde la entrega tiene el aspecto del siguiente ejemplo:
/etc/nginx/nginx.conf.default: # proxy_pass http://127.0.0.1;En este caso, se establecería proxy_pass en el archivo de configuración de NGINX. Se tiene que completar la entrada correspondiente en nginx.conf de la siguiente manera:
proxy_pass http://127.0.0.1;
proxy_set_header Proxy "";El último paso consiste en reiniciar el servidor:
sudo service nginx restartSi se transmiten solicitudes HTTP a través de un servidor HAProxy hacia tu proyecto web, puedes eliminar el encabezado Proxy antes de que el proxy envíe las solicitudes. El procedimiento es el mismo para las diferentes distribuciones de Linux. Lo primero es abrir el archivo de configuración central de la aplicación del proxy con el siguiente comando:
sudo nano /etc/haproxy/haproxy.cfgDe esta manera se abre el archivo haproxy.cfg con nano, el editor de líneas de comando utilizado arriba. Si en la instalación has indicado un directorio alternativo para HAProxy, es necesario que adaptes el comando correspondiente. En el archivo abierto puedes integrar una directiva de solicitudes HTTP para las tres secciones “frontend”, “backend” y “listen” y dicha directiva elimina el encabezado indeseado. El resultado es el siguiente:
frontend name
http-request del-header Proxy
…
backend name
http-request del-header Proxy
…
listen name
http-request del-header ProxyGuarda los cambios y reinicia el servicio HAProxy:
sudo service haproxy restartTras haber protegido la configuración del proxy con ayuda de las diferentes posibilidades de protección frente a la vulnerabilidad HTTPoxy, el paso siguiente es comprobar si esta se aplica de la manera deseada. Para ello hay aplicaciones como HTTPOXY Vulnerability Checking Tool de Luke Rehmann. Este servicio web gratuito analiza los URL para ver si cuentan con la vulnerabilidad HTTPoxy, para lo que envía una solicitud HTTP que incluye el encabezado Proxy a los URL, que a su vez son transmitidos a un servidor alternativo. Si la herramienta no recibe respuesta alguna del servidor, esto significa que el encabezado se ha bloqueado con éxito.
Para hacer uso del servicio, solo es necesario incluir el URL de la aplicación web que tiene que ser analizada en el campo de entrada y hacer clic en “Test”.
La seguridad en Internet es un tema cada vez más importante, tanto en el ámbito privado como en el empresarial. Como propietario de una página web es pertinente tomar las medidas necesarias para que los visitantes de tu web se sientan lo más seguros posible y puedas, al mismo tiempo, garantizar una transmisión de datos libre de riesgos. Así, la implementación de un certificado SSL será el primer...