¿Qué es HTTP Petición Smuggling?

El HTTP request smuggling es una vulnerabilidad que surge de inconsistencias en el análisis de peticiones HTTP entre varios dispositivos. Estas vulnerabilidades se producen cuando un dispositivo frontend (p. ej., red de distribución de contenidos, equilibrador de carga, WAF) y un dispositivo backend (p. ej., servidor web) interpretan de forma diferente el final de la petición HTTP, debido a la presencia de diferentes encabezados HTTP (es decir, Transfer-Encoding, Content-Length). Esto puede provocar la omisión de controles de seguridad, la capacidad de lanzar ataques (p. ej., XSS) contra otros usuarios, envenenamiento de caché, denegación de servicio u otros ataques en función de la aplicación. El HTTP petición smuggling también puede denominarse CWE-444, HTTP respuesta smuggling o HTTP smuggling.

Hay muchos tipos de vulnerabilidades de HTTP petición smuggling, según la versión del protocolo, el orden de los encabezados y el entorno. Desglosaremos cada una de ellas en las siguientes secciones.

Qué cubriremos:

¿Cuáles son los diferentes tipos de HTTP petición smuggling?
Contrabando de peticiones HTTP/1.1
Petición HTTP/2 smuggling
Impactos del HTTP petición smuggling
Cómo Fastly evita el HTTP petición smuggling
Cómo prevenir el contrabando de peticiones HTTP
Resumen

¿Cuáles son los diferentes tipos de HTTP petición smuggling?

Contrabando de peticiones HTTP/1.1

Las peticiones HTTP que usan la versión 1.1 pueden especificar el final de la petición mediante los encabezados Content-Length o Transfer-Encoding. Cuando los dispositivos frontend y backend no usan el mismo de estos dos encabezados para determinar el final de la petición, pueden analizar el final de la petición de forma diferente, lo que da lugar a una vulnerabilidad de HTTP request smuggling.

En los siguientes ejemplos, demostraremos el impacto del petición smuggling mediante una omisión de la autorización. En este escenario, el servidor frontend impide el acceso a la página /admin, pero no hay ninguna validación adicional en el backend. Dado que el backend tampoco realiza la validación, el request smuggling puede permitirnos eludir esta comprobación de autorización.

Vulnerabilidades CL.TE

Una vulnerabilidad CL.TE se refiere a un ataque de HTTP request smuggling en el que el frontend usa el encabezado Content-Length, pero el back-end usa el encabezado Transfer-Encoding.

En el siguiente ejemplo, el frontend utiliza el encabezado Content-Length, lee todo el contenido como una única petición y lo reenvía al back-end. Sin embargo, el servidor back-end utiliza el encabezado Transfer-Encoding e interpreta el final de la petición en 0\r\n\r\n (dos líneas nuevas después de un fragmento 0 que Transfer-Encoding utiliza para indicar el final de una petición). El back-end interpreta esto como dos peticiones.

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 46
Transfer-Encoding: chunked

1
q=smuggling

0

GET /admin HTTP/1.1
Example: x

Ahora, cuando llegan más datos a través de la conexión (p. ej., volvemos a enviar la petición), el servidor back-end los antepone a esta segunda petición smuggled porque no se terminó. Esto hace que el servidor back-end vea lo siguiente como la segunda petición:

GET /admin HTTP/1.1
Example: xPOST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

Content-Length: 46
Transfer-Encoding: chunked

1
q=smuggling

El servidor back-end interpreta esto como una petición GET para /admin, que se introdujo de contrabando más allá del servidor frontend, que solo interpretó las dos peticiones POST. Esta vulnerabilidad de petición smuggling ahora permite al atacante eludir la comprobación de autorización del frontend.

Vulnerabilidades de TE.CL

Una vulnerabilidad TE.CL se refiere a un ataque de HTTP petición smuggling en el que el frontend usa el encabezado Transfer-Encoding, pero el backend usa el encabezado Content-Length.

En el siguiente ejemplo, el frontend utiliza el encabezado Transfer-Encoding, lee todo el contenido como una única petición y lo reenvía al backend. El backend utiliza el encabezado Content-Length y, por tanto, interpreta esto como dos peticiones.

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

k0
GET /admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 150

x
0

Mientras el servidor frontend ha terminado su petición, el servidor back-end sigue esperando contenido adicional del Content-Length largo de la petición introducida de contrabando. Cuando llegan más datos a través de la conexión (por ejemplo, si enviamos la petición de nuevo), el servidor back-end los antepone a esta segunda petición introducida de contrabando porque no se terminó. Esto hace que el servidor back-end vea lo siguiente como la segunda petición:

GET /admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 141

x
0

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

k0

Ofuscación y smuggling de encabezados

Es posible que algunos dispositivos ignoren los encabezados Transfer-Encoding mal formados, mientras que otros pueden procesarlos incluso con pequeños errores (p. ej., espacios adicionales, encabezados duplicados, etc.) Si este es el caso, puede facilitar el aprovechamiento de una de las vulnerabilidades CL.TE o TE.CL mencionadas anteriormente, porque un dispositivo procesa el encabezado mal formado mientras que el otro lo ignora.

Petición HTTP/2 smuggling

Aunque el request smuggling clásico de HTTP debería mitigarse mediante HTTP/2, todavía hay formas de introducir peticiones mediante HTTP/2, especialmente cuando los servidores backend solo admiten HTTP/1.1.

HTTP/2 es un protocolo binario enviado en tramas, y cada trama va precedida de la longitud de la trama. No se requiere un encabezado Content-Length y el encabezado Transfer-Encoding no es compatible. Mostraremos estas peticiones como serían en HTTP/1.1 para facilitar la lectura, pero ten en cuenta que los datos reales enviados tienen un aspecto diferente en HTTP/2.

Degradación de HTTP/2

Cuando los dispositivos de backend (p. ej., servidor web) solo admiten HTTP/1.1, pero los dispositivos de frontend (p. ej., red de distribución de contenidos) y los clientes utilizan HTTP/2, los dispositivos de frontend reescriben la petición HTTP/2 recibida a HTTP/1.1 antes de enviarla al backend. Esto se conoce como degradación de HTTP/2, y aprovechar errores en la reescritura es la forma en que surgen las vulnerabilidades de petición smuggling.

Vulnerabilidades de H2.CL

HTTP/2 no requiere un encabezado Content-Length y, si se proporciona uno, se supone que debe validarse con respecto a la longitud calculada del mensaje. Cuando un dispositivo reescribe una petición a HTTP/1.1, debe usar la longitud calculada para el encabezado Content-Length traducido. Sin embargo, algunos dispositivos frontend pueden usar en su lugar el encabezado Content-Length proporcionado al realizar la degradación. Si esto ocurre, el backend usará un Content-Length distinto al del frontend, lo que dará lugar a una vulnerabilidad de smuggling.

Vulnerabilidades H2.TE

El encabezado Transfer-Encoding no se usa en HTTP/2 y se recomienda eliminar el encabezado o rechazar las peticiones HTTP/2 que tengan un encabezado Transfer-Encoding. Si el dispositivo frontend no hace esto y luego reescribe la petición con el encabezado Transfer-Encoding, es posible introducir el encabezado de contrabando en el backend. Para aprovechar esto, el backend tendría que admitir Transfer-Encoding en lugar de Content-Length, pero entonces sería igual que una explotación CL.TE de HTTP/1.1.

Impactos del HTTP petición smuggling

El HTTP request smuggling tiene un amplio abanico de impactos en función de la aplicación, ya que interfiere en el límite entre múltiples peticiones. En nuestros ejemplos anteriores vimos una omisión de la autorización y veremos otra adicional que afecta a otros usuarios, pero la gente de Portswigger, que lleva a cabo una amplia investigación sobre HTTP request smuggling, trata muchos más con más detalle.

Ejemplo real: aprovechar con XSS reflejado

En este ejemplo, supongamos que el servidor frontend determina la longitud de la petición en función de Content-Length, y que el servidor back-end la determina en función de Transfer-Encoding. Supongamos también que el servidor web es vulnerable a Cross-Site Scripting (XSS) reflejado cuando una carga útil está en el encabezado Referrer. Normalmente, un XSS reflejado en el encabezado Referer es difícil de aprovechar, porque no puede aprovecharse solo con un enlace como podría hacerse en un parámetro de consulta. En este escenario, un atacante envía la siguiente petición:

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 111
Transfer-Encoding: chunked

1
q=smuggling
0

GET /vulnerable-page HTTP/1.1
Referrer: ”><script>print(1)</script>
Example: x

El frontend utiliza el encabezado Content-Length y lo interpreta como una única petición, reenviándola al back-end. El back-end utiliza Transfer-Encoding y lo interpreta como dos peticiones, con la primera resaltada en rojo y la segunda en azul. La segunda petición está incompleta, por lo que el back-end espera más datos. Cuando otro usuario envía después una petición a /home, la respuesta del servidor web procede de la petición introducida de contrabando por el atacante, lo que da lugar a la distribución de la carga útil XSS reflejada en la respuesta al usuario víctima. En este escenario, el back-end interpreta la petición del usuario víctima de la siguiente manera:

GET /vulnerable-page HTTP/1.1
Referrer: "><script>print(1)</script>
Example: xGET /home HTTP/1.1
Host: example.com
...rest of victim user's request...

El usuario víctima envió una petición a /home, pero en su lugar recibió la respuesta a /vulnerable-page con la carga útil XSS reflejada. En la práctica, debido al volumen de peticiones, la reutilización de conexiones, etc., harán falta muchas peticiones para conseguir que un usuario reciba la respuesta XSS en cola, pero esto puede afectar rápidamente a una amplia variedad de usuarios al enviar rápidamente peticiones de smuggling para envenenar conexiones con cargas útiles XSS.

Cómo Fastly evita el HTTP petición smuggling

Fastly evita el HTTP request smuggling analizando las peticiones de forma estricta y conforme a las normas. Esto se hace de varias maneras:

Análisis estricto de protocolos: Fastly analiza todas las peticiones HTTP con un alto grado de rigor, de acuerdo con los estándares. Esto elimina la ambigüedad que los atacantes aprovechan para explotar vulnerabilidades de request smuggling.
Normalización de peticiones: Fastly rechaza o normaliza las peticiones ambiguas en el edge. Por ejemplo, una petición que contiene tanto un encabezado Content-Length como un encabezado Transfer-Encoding se gestionará para evitar que llegue al origen en un estado explotable.
Rechazo de peticiones no válidas: Fastly deniega las peticiones GET y HEAD que contienen un cuerpo. Cuando esto ocurre, Fastly envía una respuesta 400 Bad Request, lo que impide que la petición llegue al origen. Si se configura para permitirlo, las peticiones pass transmitirán los cuerpos de las peticiones GET y HEAD al origen. Si necesitas específicamente habilitar cuerpos para estas peticiones, debes ponerte en contacto con nuestro equipo de asistencia.

Cómo prevenir el contrabando de peticiones HTTP

Normaliza las peticiones ambiguas
- Los servidores frontend que reciben encabezados CL y TE deben normalizar las peticiones a un único mecanismo para determinar la longitud de una petición y eliminar los encabezados superfluos para evitar que los orígenes reciban peticiones ambiguas.
Rechazar peticiones malformadas (tanto HTTP/2 como HTTP/1.1)
- Rechazar las peticiones con encabezados malformados, encabezados duplicados, etc. ayudará a evitar vulnerabilidades que pueden depender de que los servidores acepten encabezados malformados. También evitará las vulnerabilidades de CL y TE en la degradación de HTTP/2 que dependen de que se reenvíen encabezados adicionales innecesarios al backend.
Validar en la degradación a HTTP/1.1
- Los servidores frontend que se degradan a HTTP/1.1 deben validar que las peticiones reescritas no estén malformadas ni sean ambiguas. Por ejemplo, después de la reescritura, un servidor frontend debe realizar la misma normalización que realizaría en una petición HTTP/1.1 normal.
Considera desactivar la reutilización de conexiones de back-end
- Muchos ataques de smuggling de peticiones aprovechan que el frontend y el backend reutilizan conexiones. El ejemplo de XSS hace esto, ya que varios usuarios que envían peticiones comparten una conexión del frontend al backend y el smuggling hace que las respuestas se mezclen. Deshabilitar la reutilización de conexiones evita este tipo de ataque, pero no evita todos los ataques de smuggling ni técnicas avanzadas como el request tunneling. Esto también puede afectar al rendimiento y es solo una partial mitigación.
Usa HTTP/2 de extremo a extremo si es posible
- HTTP/2 está protegido de forma inherente contra el petición smuggling cuando la degradación está desactivada. Siempre que sea posible, usarlo es la mejor mitigación.

Resumen

HTTP Request smuggling es una vulnerabilidad que surge de las inconsistencias en el análisis de peticiones HTTP entre varios dispositivos y puede causar efectos devastadores, como la omisión de la autorización, la capacidad de lanzar ataques (p. ej., XSS) contra otros usuarios, el envenenamiento de caché, la denegación de servicio y más. Aunque HTTP/2 y la desactivación de la degradación evitarán el request smuggling, las organizaciones también deberían considerar rechazar las peticiones malformadas, normalizar las peticiones ambiguas y validar el esquema HTTP para limitar aún más la superficie de ataque si debe admitirse la degradación.

Más información sobre la oferta de productos de seguridad de Fastly que puede ayudarte a mantenerte a salvo de los ataques de HTTP petición smuggling y mucho más.

Más información sobre la oferta de productos de seguridad de Fastly

Más información