El contrabando de solicitudes HTTP ( HRS ) es una vulnerabilidad de seguridad en el protocolo HTTP que aprovecha una inconsistencia entre la interpretación de los encabezados Content-Lengthy Transfer-Encodinglas implementaciones de servidores HTTP en una cadena de servidores proxy HTTP . [1] [2] Fue documentado por primera vez en 2005 por Linhart et al. [3]
El encabezado Transfer-Encoding funciona definiendo una directiva sobre cómo interpretar el cuerpo de la solicitud HTTP , siendo la directiva común y necesaria para este ataque la chunked transfer encoding . [4] Cuando el encabezado Transfer-Encoding está presente, se supone que el encabezado Content-Length debe omitirse. [4] Trabajando de manera similar pero con una sintaxis diferente, el encabezado Content-Length funciona especificando el tamaño en bytes del cuerpo como un valor en el encabezado mismo. [5] Las vulnerabilidades surgen cuando ambos encabezados se incluyen en una solicitud HTTP maliciosa, omitiendo las funciones de seguridad destinadas a prevenir consultas HTTP maliciosas al servidor al hacer que el servidor front-end o back-end interprete incorrectamente la solicitud. [6] El contrabando de solicitudes HTTP comúnmente toma la forma de CL.TE, TE.CL o TE.TE, aunque existen ataques más complejos que usan HRS. [6]
En este tipo de contrabando de solicitudes HTTP, el front-end procesa la solicitud utilizando el encabezado Content-Length mientras que el back-end procesa la solicitud utilizando el encabezado Transfer-Encoding. [2] El ataque se llevaría a cabo con la primera parte de la solicitud declarando un fragmento de longitud cero. [6] El servidor front-end al ver esto solo leería la primera parte de la solicitud y pasaría involuntariamente la segunda parte al servidor back-end. [6] Una vez que se pasa al servidor back-end, se trataría como la siguiente solicitud y se procesaría, llevando a cabo la solicitud oculta de los atacantes. [6]
En este tipo de contrabando de solicitudes HTTP, el front-end procesa la solicitud utilizando el encabezado Transfer-Encoding mientras que el back-end procesa la solicitud utilizando el encabezado Content-Length. [2] En este ataque, un hacker declararía la longitud válida del primer fragmento, que alberga la solicitud maliciosa y luego declararía un segundo fragmento con una longitud de 0. [6] Cuando el servidor front-end ve el segundo fragmento con una longitud de 0, cree que la solicitud está completa y la pasa al servidor back-end. [6] Sin embargo, el servidor back-end procesa la solicitud utilizando el encabezado Content-Length y, como resultado, la solicitud maliciosa que queda en el primer fragmento no se procesa hasta que se trata como si estuviera al comienzo de la siguiente solicitud en la secuencia y se lleva a cabo. [2]
En este tipo de contrabando de solicitudes HTTP, tanto el front-end como el back-end procesan la solicitud utilizando el encabezado Transfer-Encoding, pero el encabezado puede estar ofuscado de una manera (por ejemplo, mediante un formato de espacios en blanco no estándar o encabezados duplicados) que hace que uno de los servidores, pero no el otro, lo ignore. [2] El oscurecimiento del encabezado puede tomar la forma de agregar un carácter incorrecto, como Transfer-Encoding: xchunked, o un carácter de nueva línea inusual entre 'Transfer-Encoding' y ': chunked'. [6] Si uno de los servidores front-end o back-end aún procesa estas solicitudes HTTP ofuscadas, entonces el resto del ataque será similar a cómo funcionan los ataques CL.TE o TE.CL. [6]
La mejor prevención para estos ataques sería claramente si los servidores front-end y back-end interpretaran las solicitudes HTTP de la misma manera. Sin embargo, esto no suele ser una opción, ya que los balanceadores de carga admiten servidores back-end que se ejecutan en plataformas distintas y utilizan software diferente. [6] La mayoría de las variantes [ especificar ] de este ataque se pueden prevenir utilizando HTTP/2 , ya que utiliza un método diferente para determinar la longitud de una solicitud. Otro método para evitar el ataque es que el servidor front-end normalice las solicitudes HTTP antes de pasarlas al back-end, asegurándose de que se interpreten de la misma manera. [2] Configurar un firewall de aplicaciones web es otra buena forma de prevenir ataques HRS, ya que muchos cuentan con tecnología que identifica los intentos de ataque y bloquea o desinfecta las solicitudes entrantes sospechosas. [6]
Grenfeldt et al. (2021) descubrieron que la mayoría de los servidores web front-end (por ejemplo, servidores proxy) proporcionaban funciones de análisis para obstaculizar en la práctica todos los ataques HRS conocidos en los servidores web back-end. [7] Huang et al. (2022) propusieron un método que utiliza Flask para implementar funciones de análisis adecuadas que eviten los ataques HRS desde un programa front-end o un servidor web. [8]