En esta sección, explicaremos los ataques de contrabando de solicitudes HTTP y describiremos cómo pueden surgir vulnerabilidades comunes de contrabando de solicitudes.
¿Qué es el ataque HTTP Request Smuggling?
El contrabando de solicitudes HTTP es una técnica para interferir con la forma en que un sitio web procesa secuencias de solicitudes HTTP que se reciben de uno o más usuarios. Las vulnerabilidades de contrabando de solicitudes suelen ser de naturaleza crítica y permiten a un atacante eludir los controles de seguridad, obtener acceso no autorizado a datos confidenciales y comprometer directamente a otros usuarios de la aplicación.
El contrabando de solicitudes se asocia principalmente con solicitudes HTTP/1. Sin embargo, los sitios web que admiten HTTP/2 pueden ser vulnerables, dependiendo de su arquitectura de back-end.
¿Qué sucede en un ataque HTTP request smuggling?
Las aplicaciones web actuales emplean con frecuencia cadenas de servidores HTTP entre los usuarios y la lógica de aplicación definitiva. Los usuarios envían solicitudes a un servidor de aplicaciones para el usuario (a veces llamado equilibrador de carga o proxy inverso) y este servidor reenvía solicitudes a uno o más servidores de servicios de fondo. Este tipo de arquitectura es cada vez más común y, en algunos casos, inevitable, en las aplicaciones modernas basadas en la nube.
Cuando el servidor de front-end reenvía solicitudes HTTP a un servidor de back-end, normalmente envía varias solicitudes a través de la misma red de back-end. conexión, porque esto es mucho más eficiente y con mayor rendimiento. El protocolo es muy sencillo; Las solicitudes HTTP se envían una tras otra y el servidor receptor tiene que determinar dónde termina una solicitud y comienza la siguiente:
En esta situación, es crucial que los sistemas front-end y back-end acuerden los límites entre las solicitudes. De lo contrario, un El atacante podría enviar una solicitud ambigua que los sistemas front-end y back-end interpretan de manera diferente:
Aquí, el atacante hace que parte de su solicitud de front-end sea interpretada por el servidor de back-end como el inicio de la siguiente solicitud. Es se antepone efectivamente a la siguiente solicitud y, por lo tanto, puede interferir con la forma en que la aplicación procesa esa solicitud. Esta es una solicitud ataque de contrabando, y puede tener resultados devastadores.
Realice análisis dinámicos recurrentes (DAST) en miles de sitios. Utilice acciones masivas para gestionar el escaneo a escala o configurar sitios individualmente; todo lo que necesitas es una URL.
Conocer…
¿Cómo surgen las vulnerabilidades de contrabando de solicitudes HTTP?
La mayoría de las vulnerabilidades de contrabando de solicitudes HTTP surgen porque la especificación HTTP/1 proporciona dos formas diferentes de especificar dónde se envía una solicitud. termina: el encabezado Content-Length y el encabezado Transfer-Encoding.
El encabezado Content-Length es sencillo: especifica la longitud del cuerpo del mensaje en bytes. Para ejemplo:
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smuggling
El encabezado Transfer-Encoding se puede utilizar para especificar que el cuerpo del mensaje utiliza codificación fragmentada. Este significa que el cuerpo del mensaje contiene uno o más fragmentos de datos. Cada fragmento consta del tamaño del fragmento en bytes (expresado en hexadecimal), seguido de una nueva línea, seguido del contenido del fragmento. El mensaje finaliza con un fragmento de tamaño cero. Por ejemplo:
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
b
q=smuggling
0
Como la especificación HTTP/1 proporciona dos métodos diferentes para especificar la longitud de los mensajes HTTP, es posible que un solo mensaje para utilizar ambos métodos a la vez, de modo que entren en conflicto entre sí. La especificación intenta evitar este problema indicando que si los encabezados Content-Length y Transfer-Encoding son presente, entonces se debe ignorar el encabezado Content-Length. Esto podría ser suficiente para evitar ambigüedades. cuando solo hay un servidor en juego, pero no cuando dos o más servidores están encadenados. En esta situación, pueden surgir problemas para dos razones:
- Algunos servidores no admiten el encabezado
Transfer-Encodingen las solicitudes. - Se puede inducir a algunos servidores que admiten el encabezado
Transfer-Encodinga no procesarlo si el El encabezado está ofuscado de alguna manera.
Si los servidores front-end y back-end se comportan de manera diferente en relación con (posiblemente ofuscado) Transfer-Encoding encabezado, entonces podrían no estar de acuerdo sobre los límites entre solicitudes sucesivas, lo que generaría vulnerabilidades de contrabando de solicitudes.
Cómo realizar un ataque HTTP request smuggling
Los ataques clásicos de contrabando de solicitudes implican colocar tanto el encabezado Content-Length como el Transfer-Encoding encabezado en una única solicitud HTTP/1 y manipularlos para que los servidores front-end y back-end procesen la solicitud de manera diferente. El La forma exacta en que se hace esto depende del comportamiento de los dos servidores:
- CL.TE: el servidor front-end utiliza el encabezado
Content-Lengthy el servidor back-end utiliza el encabezadoTransfer-Encoding. - TE.CL: el servidor front-end usa el encabezado
Transfer-Encodingy el servidor back-end usa el encabezadoContent-Length. - TE.TE: los servidores front-end y back-end admiten el encabezado
Transfer-Encoding, pero uno de los Se puede inducir a los servidores a no procesarlo ofuscando el encabezado de alguna manera.
Vulnerabilidades de CL.TE
Aquí, el servidor de aplicaciones para el usuario utiliza el encabezado Content-Length y el servidor de servicios de fondo utiliza el encabezado Transfer-Encoding. Podemos realizar un simple ataque de contrabando de solicitudes HTTP de la siguiente manera:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked
0
SMUGGLED
El servidor de aplicaciones para el usuario procesa el encabezado Content-Length y determina que el cuerpo de la solicitud tiene 13 bytes. de largo, hasta el final de SMUGGLED. Esta solicitud se reenvía al servidor de fondo.
El servidor de fondo procesa el encabezado Transfer-Encoding y, por lo tanto, trata el cuerpo del mensaje como si estuviera usando codificación fragmentada. Procesa el primer fragmento, que se indica que tiene una longitud cero, por lo que se trata como si finalizara la solicitud. El Los siguientes bytes, SMUGGLED, se dejan sin procesar y el servidor back-end los tratará como si fueran los inicio de la siguiente solicitud de la secuencia.
Vulnerabilidades de TE.CL
Aquí, el servidor de aplicaciones para el usuario utiliza el encabezado Transfer-Encoding y el servidor de servicios de fondo utiliza el encabezado Content-Length. Podemos realizar un simple ataque de contrabando de solicitudes HTTP de la siguiente manera:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked
8
SMUGGLED
0
El servidor de aplicaciones para el usuario procesa el encabezado Transfer-Encoding y, por lo tanto, trata el cuerpo del mensaje como si estuviera usando codificación fragmentada. Procesa el primer fragmento, que tiene una longitud de 8 bytes, hasta el inicio de la línea que sigue a SMUGGLED. Procesa el segundo fragmento, que se indica que tiene longitud cero, por lo que se trata como terminante. la solicitud. Esta solicitud se reenvía al servidor de fondo.
El servidor back-end procesa el encabezado Content-Length y determina que el cuerpo de la solicitud tiene 3 bytes. de largo, hasta el inicio de la línea que sigue a 8. Los siguientes bytes, que comienzan con SMUGGLED, no se procesan y el servidor back-end los tratará como el inicio del siguiente solicitud en la secuencia.
Comportamiento TE.TE: ofuscar el encabezado TE
Aquí, los servidores front-end y back-end admiten el encabezado Transfer-Encoding, pero uno de los servidores Se puede inducir a no procesarlo ofuscando el encabezado de alguna manera.
Existen formas potencialmente infinitas de ofuscar el encabezado Transfer-Encoding. Por ejemplo:
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding
: chunked
Cada una de estas técnicas implica una desviación sutil de la especificación HTTP. Código del mundo real que implementa una especificación de protocolo. rara vez se adhiere a él con absoluta precisión, y es común que diferentes implementaciones toleren diferentes variaciones del especificación. Para descubrir una vulnerabilidad TE.TE, es necesario encontrar alguna variación del encabezado Transfer-Encoding de modo que solo uno de los servidores front-end o back-end lo procese, mientras que el otro servidor lo ignora.
Dependiendo de si se puede inducir al servidor front-end o back-end a no procesar el encabezado Transfer-Encoding ofuscado, el resto del ataque tomará la misma forma que para el CL. TE o TE.CL vulnerabilidades ya descritas.
Cómo prevenir las vulnerabilidades de HTTP request smuggling
Las vulnerabilidades de contrabando de solicitudes HTTP surgen en situaciones en las que el servidor de aplicaciones para el usuario y el servidor de servicios de fondo utilizan diferentes mecanismos para determinar los límites entre las solicitudes. Esto puede deberse a discrepancias entre si los servidores HTTP/1 utilizan el encabezado Content-Length o la codificación de transferencia fragmentada para determinar dónde termina cada solicitud. En entornos HTTP/2, la práctica común de degradar las solicitudes HTTP/2 para el back-end también está plagada de problemas y permite o simplifica una serie de ataques adicionales.
Para evitar vulnerabilidades de contrabando de solicitudes HTTP, recomendamos las siguientes medidas de alto nivel:
Utilice HTTP/2 de extremo a extremo y deshabilite la degradación de HTTP si es posible. HTTP/2 utiliza un mecanismo robusto para determinar la longitud de las solicitudes y, cuando se utiliza de un extremo a otro, está inherentemente protegido contra el contrabando de solicitudes. Si no puede evitar la degradación de HTTP, asegúrese de validar la solicitud reescrita con la especificación HTTP/1.1. Por ejemplo, rechace solicitudes que contengan nuevas líneas en los encabezados, dos puntos en los nombres de los encabezados y espacios en el método de solicitud.
Haga que el servidor de front-end normalice las solicitudes ambiguas y haga que el servidor de back-end rechace las que aún sean ambiguas, cerrando la conexión TCP en el proceso.
Nunca asuma que las solicitudes no tendrán cuerpo. Esta es la causa fundamental de las vulnerabilidades de desincronización tanto de CL.0 como del lado del cliente.
De forma predeterminada, se descarta la conexión si se activan excepciones a nivel de servidor al manejar solicitudes.
Si dirige el tráfico a través de un proxy de reenvío, asegúrese de que HTTP/2 ascendente esté habilitado si es posible.
Como hemos demostrado en los materiales de aprendizaje, deshabilitar la reutilización de conexiones back-end ayudará a mitigar ciertos tipos de ataques, pero esto aún no lo protege de túnel de solicitudes. ataques.
NORTH NETWORKS es Distribuidor Oficial, brinda licencias nuevas y renovaciones a nivel empresarial.
Pongase en contacto y le ayudaremos a analizar sus requerimientos para poder brindarle la herramienta que mejor se ajuste a sus proyectos.
Si te ha gustado, ¡compártelo con tus amigos!
