¿Qué es el HTTP solicitud Smuggling?

El HTTP request smuggling es una vulnerabilidad que surge por inconsistencias en el análisis de solicitudes HTTP entre varios dispositivos. Estas vulnerabilidades ocurren cuando un dispositivo frontend (p. ej., Red de distribución de contenido, balanceo de carga, WAF) y un dispositivo backend (p. ej., servidor web) interpretan de forma diferente el final de la solicitud HTTP, debido a la presencia de distintos 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 según la aplicación. El HTTP solicitud smuggling también puede denominarse CWE-444, HTTP respuesta smuggling o HTTP smuggling.

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

Qué cubriremos:

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

¿Cuáles son los diferentes tipos de HTTP solicitud smuggling?

smuggling de solicitudes HTTP/1.1

Las solicitudes HTTP que usan la versión 1.1 pueden especificar el final de su solicitud 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 solicitud, pueden parse el final de la solicitud de forma diferente, lo que genera una vulnerabilidad de HTTP request smuggling.

En los siguientes ejemplos, demostraremos el impacto de la solicitud smuggling mediante una omisión de autorización. En este escenario, el servidor frontend impide el acceso a la página /admin, pero no hay validación adicional en el backend. Como el backend tampoco realiza validación, el solicitud smuggling puede permitirnos omitir esta verificación de autorización.

Vulnerabilidades CL.TE

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

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

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 (por ejemplo, enviamos la solicitud de nuevo), el servidor back-end los antepone a esta segunda solicitud infiltrada porque no se terminó. Esto hace que el servidor back-end vea lo siguiente como la segunda solicitud:

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 solicitud GET para /admin, que fue introducida de contrabando más allá del servidor frontend, que solo interpretó las dos solicitudes POST. Esta vulnerabilidad de solicitud smuggling ahora permite que el atacante omita la verificación de autorización del frontend.

Vulnerabilidades de TE.CL

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

En el siguiente ejemplo, el frontend usa el encabezado Transfer-Encoding, lee todo el contenido como una sola solicitud y lo reenvía al backend. El backend usa el encabezado Content-Length y, por lo tanto, interpreta esto como dos solicitudes.

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 solicitud, el servidor backend sigue esperando contenido adicional del Content-Length largo en la solicitud introducida de contrabando. Cuando llegan más datos a través de la conexión (p. ej., enviamos la solicitud de nuevo), el servidor backend los antepone a esta segunda solicitud introducida de contrabando porque no se terminó. Esto hace que el servidor backend vea lo siguiente como la segunda solicitud:

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 contrabando de encabezados

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

Contrabando de solicitudes HTTP/2

Aunque el contrabando clásico de solicitudes HTTP debería mitigarse mediante HTTP/2, todavía hay formas de introducir solicitudes mediante HTTP/2, en particular cuando los servidores backend solo admiten HTTP/1.1.

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

Degradación de HTTP/2

Cuando los dispositivos de back-end (por ejemplo, servidor web) solo admiten HTTP/1.1, pero los dispositivos de frontend (por ejemplo, Red de distribución de contenido) y los clientes usan HTTP/2, los dispositivos de frontend reescribirán la solicitud HTTP/2 recibida a HTTP/1.1 antes de enviarla al back-end. Esto se conoce como degradación de HTTP/2, y explotar errores en la reescritura es la forma en que surgen las vulnerabilidades de smuggling de solicitudes.

Vulnerabilidades de H2.CL

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

Vulnerabilidades H2.TE

El encabezado Transfer-Encoding no se usa en HTTP/2, y se recomienda quitar el encabezado o rechazar las solicitudes HTTP/2 que tengan un encabezado Transfer-Encoding. Si el dispositivo frontend no hace esto y luego reescribe la solicitud con el encabezado Transfer-Encoding, es posible pasar el encabezado al backend. Para explotar esto, sería necesario que el backend admitiera Transfer-Encoding sobre Content-Length, pero entonces sería lo mismo que una explotación CL.TE de HTTP/1.1.

Impactos del contrabando de solicitudes HTTP

El HTTP request smuggling tiene impactos de gran alcance según la aplicación porque interfiere con el límite entre múltiples solicitudes. Nuestros ejemplos anteriores cubrieron una omisión de autorización y cubriremos una adicional que afecta a otros usuarios, pero hay muchos más explicados con más detalle por la gente de Portswigger, que realiza una amplia investigación sobre HTTP request smuggling.

Ejemplo real: explotar con XSS reflejado

En este ejemplo, supongamos que el servidor frontend determina la longitud de la solicitud en función de Content-Length, y que el servidor backend 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 explotar, porque no puede explotarse solo con un enlace como podría hacerse en un parámetro de consulta. En este escenario, un atacante envía la siguiente solicitud:

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 usa el encabezado Content-Length y lo interpreta como una sola solicitud, reenviándola al back-end. El back-end usa Transfer-Encoding y lo interpreta como dos solicitudes, con la primera resaltada en rojo y la segunda en azul. La segunda solicitud está incompleta, por lo que el back-end espera más datos. Cuando otro usuario envía una solicitud a /home después de esto, la respuesta del servidor web proviene de la solicitud introducida de contrabando por el atacante, lo que provoca la distribución de la carga útil de XSS reflejado en la respuesta al usuario víctima. En este escenario, el back-end interpreta la solicitud 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 solicitud a /home, pero en su lugar recibió la respuesta a /vulnerable-page con la carga útil de XSS reflejado. En la práctica, debido al volumen de solicitudes, la reutilización de conexiones, etc., se necesitarán muchas solicitudes para que un usuario reciba la respuesta XSS en cola, pero esto puede afectar rápidamente a una amplia variedad de usuarios al enviar con rapidez solicitudes de smuggling para envenenar conexiones con cargas útiles XSS.

Cómo Fastly evita el HTTP smuggling de solicitudes

Fastly evita el contrabando de solicitudes HTTP al analizar las solicitudes de forma estricta y conforme a las normas. Esto se hace de varias maneras:

Análisis estricto de protocolos: Fastly parse todas las solicitudes HTTP con un alto grado de rigor, en cumplimiento de los estándares. Esto elimina la ambigüedad que los atacantes usan para explotar vulnerabilidades de contrabando de solicitudes.
Normalización de solicitudes: Fastly rechaza o normaliza las solicitudes ambiguas en el edge. Por ejemplo, una solicitud que contiene tanto un encabezado Content-Length como un encabezado Transfer-Encoding se gestionará para evitar que llegue a tu origen en un estado explotable.
Rechazo de solicitudes no válidas: Fastly rechaza las solicitudes GET y HEAD que contienen un cuerpo. Cuando esto ocurre, Fastly envía una respuesta 400 Bad Request, lo que evita que la solicitud llegue al origen. Si está configurado para permitirlo, las solicitudes pass transmitirán los cuerpos de las solicitudes GET y HEAD al origen. Si tienes una necesidad específica de habilitar cuerpos para estas solicitudes, debes comunicarte con nuestro equipo de soporte.

Cómo prevenir el contrabando de solicitudes HTTP

Normaliza las solicitudes ambiguas
- Los servidores frontend que reciben encabezados CL y TE deben normalizar las solicitudes a un solo mecanismo para determinar la longitud de una solicitud y eliminar los encabezados adicionales para evitar que los orígenes reciban solicitudes ambiguas.
Rechaza solicitudes con formato incorrecto (tanto HTTP/2 como HTTP/1.1)
- Rechazar solicitudes con encabezados malformados, encabezados duplicados, etc. ayudará a prevenir vulnerabilidades que pueden depender de que los servidores acepten encabezados malformados. También evitará las vulnerabilidades CL y TE de degradación de HTTP/2 que dependen de que se reenvíen encabezados adicionales innecesarios al back-end.
Validar en degradación a HTTP/1.1
- Los servidores frontend que cambian a HTTP/1.1 deben validar que las solicitudes 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 haría en una solicitud HTTP/1.1 normal.
Considera deshabilitar la reutilización de conexiones de back-end
- Muchos ataques de solicitud de contrabando aprovechan que el frontend y el backend reutilizan conexiones. El ejemplo de XSS hace esto, ya que varios usuarios que envían solicitudes 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 la tunelización de solicitudes. Esto también puede afectar el rendimiento y es solo una mitigación "partial".
Usa HTTP/2 de extremo a extremo si es posible
- HTTP/2 está protegido de forma inherente contra el contrabando de solicitudes cuando la degradación está deshabilitada. Cuando sea posible, usarla es la mejor mitigación.

Resumen

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

Obtén más información sobre los productos de seguridad de Fastly que pueden ayudarte a mantenerte a salvo de los ataques de HTTP request smuggling y más.

Más información sobre los productos de seguridad de Fastly

Más información