Los riesgos de usar HTTP son cada vez mayores, pero controlables.

Nos guste o no, HTTP es el protocolo de transporte de aplicação de facto de la era moderna. Lo usamos en todas partes. Es tan omnipresente como IP y TCP, y cumple prácticamente el mismo propósito. Su único objetivo es transportar el oro digital de las empresas actuales: los datos.

Es irrelevante si esos datos están en formato JSON, XML o codificados en URL. Es el protocolo HTTP que utilizan las aplicaciones y los dispositivos para comunicarse con servidores y servicios en la nube y 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 una variedad de datos, desde binarios hasta texto. Lo usamos para transmitir datos, recuperar datos y recopilar datos.

Los atacantes lo usan libremente porque, como se mencionó, es un protocolo basado en texto con reglas bastante laxas con respecto a las extensiones de los encabezados que especifican todo, desde qué acción espera el cliente que realice el servidor (el "método" HTTP) hasta el recurso que se solicita (el URI) y qué tipo de contenido se puede aceptar (los encabezados "Aceptar"). Estas reglas son laxas para permitir la extensibilidad.

Por ejemplo, el encabezado X-Forwarded-For se introdujo como un medio para garantizar que los desarrolladores pudieran "ver" la dirección IP original del cliente. En ciertas arquitecturas, particularmente aquellas en las que los intermediarios actúan como servidores proxy completos, esta información puede perderse. Algunas aplicações necesitan esos datos y, por eso, los desarrolladores (y proveedores de redes) ampliaron el protocolo HTTP introduciendo un encabezado personalizado. Esto es parte de la especificación HTTP; permite la innovación y la introducción de nuevos comportamientos y capacidades sin requerir cambios en el protocolo. Es algo bueno.

Excepto cuando no lo es.

No es bueno que los desarrolladores de servidores que admiten HTTP o los responsables de proteger las aplicações que dependen de HTTP no tengan en cuenta esta flexibilidad.

A continuación se muestra una pequeña muestra de CVE relacionados con HTTP que explotan una vulnerabilidad en los encabezados HTTP:

Honestamente, una búsqueda entre los CVE conocidos de vulnerabilidades HTTP arroja una lista excesivamente larga (e incluye una amplia variedad de proveedores y software) que no voy a duplicar aquí. Una parte importante de estos generalmente se activan a través del abuso de un encabezado HTTP.

Una nota sobre Optionsbleed 

Optionsbleed es una de las vulnerabilidades más recientes. Lo menciono porque existe en el propio Apache HTTP. Dado que Netcraft estima actualmente que Apache se ejecuta en “más de 2,8 millones de computadoras con acceso a Internet que actualmente ejecutan varias versiones y derivados de Apache httpd , lo que le otorga una participación del 42,8 % de todas las computadoras con acceso a Internet”, las vulnerabilidades en este sistema se convierten en un riesgo significativo. Afortunadamente, esta vulnerabilidad particular se activa a través de un encabezado HTTP, pero también requiere la existencia de una directiva Limits mal configurada dentro del archivo .htaccess . Esta publicación de Sophos ofrece una excelente descripción general de los sangrientos detalles técnicos, si así lo desea. El resumen es que si existe una configuración incorrecta, un atacante puede explotar una vulnerabilidad en Apache a través del encabezado del método HTTP y (así parece) forzar al servidor a “extraer” datos que pertenecen a, bueno, otra persona.

Ahora bien, he dicho todo eso para poder decir esto: la seguridad de las aplicaciones es una pila. Esa pila incluye las plataformas (y, por lo tanto, los protocolos) de los que dependen las aplicações . Como HTTP.

Necesitamos hacer un mejor trabajo para proteger el HTTP y evitar que se abuse de él para comprometer la seguridad. Lo importante no es si se trata de una fuga de datos, un ataque de denegación de servicio o un acceso remoto . Son todos impactos negativos. Necesitamos hacer un mejor trabajo para reconocer que HTTP es una superficie de ataque cada vez más popular. Que esté basado en texto significa que toda la interacción entre un cliente y el servicio HTTP debe clasificarse como entrada del usuario .

Esto debería, a su vez, fomentar una estrategia de seguridad que incluya la desinfección. de esa entrada. Sí, eso significa aplicación de protocolo y limpieza ascendente (antes de que llegue a un servidor HTTP potencialmente vulnerable).

Esto significa que un firewall de aplicação web o un proxy programable debe estar delante de cualquier servicio HTTP público y participar activamente en la limpieza de solicitudes HTTP entrantes.

La razón de esto se basa en la forma en que las plataformas web procesan los encabezados HTTP, es decir, antes de que un desarrollador vea la solicitud. Por lo tanto, no podemos necesariamente señalar a los desarrolladores y culpar a las prácticas de codificación inseguras por las vulnerabilidades a nivel de plataforma.

La solución definitiva, por supuesto, es aplicar parches. Siempre que (1) se entere de la vulnerabilidad el día cero, (2) haya un parche disponible el día cero y (3) se sienta cómodo implementando un parche potencialmente no probado en los sistemas de producción.

Es necesario aplicar un parche, no me malinterpretes, pero existe una brecha entre la divulgación, el descubrimiento, la disponibilidad y la aplicação. En esa brecha reside el riesgo: el riesgo de que una vulnerabilidad muy fácil de explotar se utilice en su contra.

La penúltima solución es garantizar que exista un sistema (una plataforma) en el que pueda implementar soluciones de remediación inmediata , como scripts o escaneo basado en firmas, para evitar la explotación mientras se prepara para aplicar el parche.

La limpieza de los datos entrantes y la aplicación de la corrección del protocolo deberían ser parte integral de cualquier política de seguridad corporativa.

El protocolo HTTP es cada vez más riesgoso, pero también es manejable si recordamos que la seguridad de las aplicaciones es una pila y luego avanzamos para implementar protecciones en cada capa de esa pila.