Los riesgos de usar HTTP están aumentando, pero son manejables

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Nos guste o no, HTTP es, de facto, el protocolo de transporte de aplicaciones de la era moderna. Lo utilizamos en todas partes. Es tan omnipresente como IP y TCP, y cumple prácticamente la misma función. Su único objetivo es transportar el oro digital de las empresas actuales: los datos.

Es irrelevante que esos datos estén en formato JSON, XML o codificados para URL. HTTP es el protocolo que utilizan las aplicaciones y los dispositivos para comunicarse con servidores y servicios tanto en la nube como en las instalaciones del centro de datos.

Sin embargo, a diferencia de IP y TCP, HTTP es un protocolo basado en texto. Es muy flexible y puede transportar diversos tipos de datos, desde datos binarios hasta texto. Lo utilizamos para transmitir, recuperar y recopilar datos.

Los atacantes lo utilizan profusamente porque, como ya se ha mencionado, es un protocolo basado en texto con reglas bastante permisivas en cuanto a las extensiones de las cabeceras, que especifican desde la acción que el cliente espera que realice el servidor (el «método» HTTP) hasta el recurso solicitado (el URI) o el tipo de contenido que se puede aceptar (las cabeceras «Accept»). Estas reglas son permisivas para facilitar la extensibilidad.

Por ejemplo, la cabecera X-Forwarded-For se introdujo para garantizar que los desarrolladores pudieran «ver» la dirección IP original del cliente. En determinadas arquitecturas —especialmente aquellas en las que los intermediarios actúan como proxies completos—, esta información puede perderse. Algunas aplicaciones necesitan esos datos, por lo que los desarrolladores (y los proveedores de soluciones de red) ampliaron el protocolo HTTP mediante la introducción de una cabecera personalizada. Esto forma parte de la especificación HTTP y permite innovar e incorporar nuevos comportamientos y funcionalidades sin necesidad de modificar el protocolo. Es algo positivo.

Excepto cuando no lo es.

No es bueno que los desarrolladores de los servidores compatibles con HTTP o los responsables de proteger las aplicaciones que dependen de HTTP no tengan en cuenta esta flexibilidad.

A continuación se muestra una pequeña selección de CVE relacionados con HTTP que aprovechan una vulnerabilidad en las cabeceras HTTP:

Sinceramente, una búsqueda entre las CVE conocidas de vulnerabilidades HTTP devuelve una lista excesivamente larga (que incluye una gran variedad de proveedores y software), por lo que no voy a reproducirla aquí. Una parte importante de ellas suele activarse mediante el uso indebido de una cabecera HTTP.

Una nota sobre Optionsbleed

Optionsbleed es una de las vulnerabilidades más recientes. La destaco porque se encuentra en el propio Apache HTTP. Dado que Netcraft estima actualmente que «más de 2,8 millones de equipos expuestos a Internet ejecutan diversas versiones y derivados de Apache httpd, lo que supone una cuota del 42,8 % de todos los equipos expuestos a Internet», sus vulnerabilidades representan un riesgo considerable. Por suerte, esta vulnerabilidad concreta se activa mediante una cabecera HTTP, pero también requiere que exista una directiva Limits mal configurada en el archivo .htaccess . Esta publicación de Sophos ofrece un excelente resumen de los escabrosos detalles técnicos, por si te interesan. En resumen, si existe esa configuración incorrecta, un atacante puede aprovechar una vulnerabilidad de Apache a través de la cabecera del método HTTP y, al parecer, obligar al servidor a «sangrar» datos que pertenecen a otra persona.

Ahora bien, he dicho todo eso para poder decir lo siguiente: la seguridad de las aplicaciones se estructura en capas. Esas capas incluyen las plataformas (y, por tanto, los protocolos) de las que dependen las aplicaciones. Como HTTP.

Debemos proteger mejor HTTP para evitar que se utilice de forma maliciosa y se comprometa la seguridad. No importa si se trata de una filtración de datos, un ataque de denegación de servicio (DoS) o un acceso remoto: todas estas consecuencias son perjudiciales. Debemos ser más conscientes de que HTTP es una superficie de ataque cada vez más habitual. El hecho de que esté basado en texto implica que toda la interacción entre un cliente y el servicio HTTP debe clasificarse como entrada del usuario.

Eso, a su vez, debería fomentar una estrategia de seguridad que incluya el saneamiento de esos datos de entrada. Sí, eso implica aplicar estrictamente el protocolo y depurar los datos en una fase anterior (antes de que lleguen a un servidor HTTP potencialmente vulnerable).

Eso significa que un firewall de aplicaciones web o un proxy programable debe situarse delante de cualquier servicio HTTP de acceso público y filtrar activamente las solicitudes HTTP entrantes.

La razón radica en la forma en que las plataformas web procesan las cabeceras HTTP, es decir, antes de que un desarrollador llegue siquiera a ver la solicitud. Por tanto, no podemos necesariamente señalar a los desarrolladores y culpar a unas prácticas de programación poco seguras de las vulnerabilidades de la plataforma.

Aplicar parches es, por supuesto, la solución definitiva. Siempre que (1) tenga conocimiento de la vulnerabilidad el mismo día en que se descubre, (2) haya un parche disponible ese mismo día y (3) esté dispuesto a implementar en los sistemas de producción un parche que podría no haberse probado.

Es necesario aplicar parches, no me malinterprete, pero existe un intervalo entre la divulgación, el descubrimiento, la disponibilidad y la aplicación. En ese intervalo reside el riesgo: el riesgo de que se aproveche contra usted una vulnerabilidad muy fácil de explotar.

La penúltima solución consiste en asegurarse de que exista un sistema (una plataforma) en el que se puedan implementar de inmediato soluciones correctivas, como scripts o análisis basados en firmas, para evitar que se explote la vulnerabilidad mientras se prepara el parche.

La depuración de los datos entrantes y la aplicación estricta de los protocolos deben ser elementos esenciales de cualquier política de seguridad corporativa.

HTTP entraña cada vez más riesgos, pero estos también se pueden gestionar si se tiene presente que la seguridad de las aplicaciones se estructura en capas y se implementan medidas de protección en cada una de ellas.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie