Análisis Profundo de Ataques HTTP Request Smuggling
Resumen del artículo
Por qué importa este artículo
Cuando un reverse proxy y un servidor backend no se ponen de acuerdo sobre dónde termina un request HTTP y dónde empieza el siguiente, un atacante puede envenenar el request de otro usuario, bypassear WAFs y robar sesiones. Este post recorre cada variante—CL.TE, TE.TE, TE.CL, e incluso el bug de Gunicorn con Sec-Websocket-Key1—con exploits reales de HTB, desgloses de payloads y workflows de Burp Repeater. Vas a aprender a identificar, explotar y defender contra request smuggling a nivel de protocolo.
Introducción a los Ataques de HTTP Request Smuggling/Desync
HTTP Request Smuggling, a veces también conocido como Desync Attacks, crea una desincronización entre el reverse proxy y el web server detrás de él. Esta técnica avanzada le permite a un atacante bypassear controles de seguridad como WAFs o incluso comprometer a otros usuarios influyendo en sus requests.
Como HTTP es un protocolo stateless, muchas veces vemos los HTTP requests de forma aislada entre sí. Sin embargo, HTTP/1.1 permite la reutilización de TCP sockets para enviar múltiples requests y responses para mejorar el rendimiento. En estos casos, el TCP stream contiene múltiples HTTP requests (pipelining).
Para determinar dónde termina un request y comienza el siguiente, el web server necesita conocer la longitud del body de cada request. Los headers HTTP Content-Length (CL) o Transfer-Encoding (TE) se utilizan para este propósito. Mientras que el header Content-Length especifica la longitud del body del request en bytes, el header Transfer-Encoding puede indicar un chunked encoding, lo que significa que el body del request contiene múltiples chunks de datos.
En contraste, HTTP/2 es un protocolo binario que ofrece mejoras de rendimiento sobre el HTTP/1.1 basado en texto, codificando mensajes de manera eficiente y definiendo la longitud de su body. Sin embargo, puede ser convertido a HTTP/1.1 por intermediarios, introduciendo potencialmente vulnerabilidades...
Como se mencionó antes, los ataques de Desync o Request Smuggling se consideran un vector de ataque avanzado que explota discrepancias entre los sistemas frontend y backend al parsear HTTP requests entrantes. Estos ataques fuerzan un desacuerdo en los límites del request entre los dos sistemas, causando así una desincronización.
El sistema frontend puede incluir cualquier sistema intermediario como un reverse proxy, web cache o web application firewall (WAF), mientras que el sistema backend es típicamente el web server. Para entender completamente lo que pasa detrás de escena, se recomienda tener algo de conocimiento sobre los protocolos TCP y HTTP.
TCP Stream de HTTP requests
Cuando HTTP quiere transmitir un mensaje, hace streaming del contenido de los datos del mensaje, en orden, a través de una conexión TCP abierta. TCP toma el stream de datos, lo corta en chunks llamados segmentos, y transporta estos segmentos a través de Internet en sobres llamados IP packets. Todo este proceso es manejado por el software TCP/IP; el programador HTTP no ve nada de esto.
Cada segmento TCP es transportado por un IP packet de una dirección IP a otra. Cada uno de estos IP packets contiene:
- Un IP packet header (generalmente 20 bytes)
- Un TCP segment header (generalmente 20 bytes)
- Un chunk de datos TCP (0 o más bytes)
El IP header incluye las direcciones IP de origen y destino, el tamaño y otras flags. El TCP segment header incluye los números de puerto TCP, control flags y valores numéricos usados para el ordenamiento de datos y verificación de integridad.
Los HTTP requests y responses se transmiten usando TCP. En HTTP/1.0, cada HTTP request se enviaba por un TCP socket separado (al menos, antes de la expansión de esta versión). Sin embargo, desde HTTP/1.1, los requests típicamente no se transmiten por conexiones TCP separadas, sino que se usa la misma conexión TCP para transmitir múltiples pares de request-response (Pipelining).
Este método permite un mejor rendimiento ya que establecer conexiones TCP lleva tiempo. Si un nuevo HTTP request requiriera una nueva conexión TCP, el overhead sería mucho mayor. Particularmente, en entornos donde un reverse proxy está delante del web server real y todos los requests se transmiten desde el reverse proxy al web server, el TCP socket generalmente se mantiene abierto y se reutiliza para todos los requests.
Como TCP es orientado a stream, múltiples HTTP requests se envían subsecuentemente en el mismo TCP stream. El TCP stream contiene todos los HTTP requests uno tras otro ya que no hay separador entre los requests. Considerá esta representación simplificada de un TCP stream que contiene dos HTTP requests: un POST request en rojo y un GET request en verde:
En el ejemplo mencionado, para que el reverse proxy y el web server parseen los HTTP requests correctamente, ambos necesitan reconocer dónde termina el request actual y comienza el siguiente. En otras palabras, ambos sistemas deben identificar los límites del request dentro del TCP stream. Para este caso particular, especificamos un CL de 5 para enviar el primer request, comunicando así el límite del primer mensaje HTTP entre HELLO y GET.
Content-Length vs Transfer-Encoding
Además, para determinar la longitud del body del request actual, podemos usar HTTP headers. Específicamente, los headers Content-Length (CL) y Transfer-Encoding (TE) se utilizan para determinar la longitud del body de un HTTP request. Veamos cómo estos headers indican la longitud del request. Funcionan de manera diferente, así que profundicemos un poco más en eso.
Content-Length
El header CL (Content-Length) se usa comúnmente y seguramente lo encontraste muchas veces al trabajar con aplicaciones web. Especifica la longitud en bytes del body del mensaje en el header HTTP Content-Length. Veamos un ejemplo de request:
Transfer-Encoding
Además, el header TE (Transfer-Encoding) puede especificar un encoding chunked con esta directiva, entre otras como compress, deflate y gzip, que no delimitan el tamaño del HTTP request. Veamos el mismo request usando chunked encoding:
El header HTTP Transfer-Encoding especifica un chunked encoding. Esto significa que el body consiste en chunks de datos, cada uno precedido por su tamaño en hexadecimal en una línea separada, seguido del payload del chunk. El request concluye con un chunk de tamaño 0, indicando el final. Como se ilustra, el request incluye un chunk de tamaño 0x1d, equivalente a 29 en decimal, seguido del mismo payload que el request anterior. El request luego termina con el chunk vacío.
Es importante notar que los tamaños de los chunks y los chunks mismos están separados por la secuencia de control CRLF (Carriage Return Line Feed). Al mostrar los caracteres CRLF, el body del request se ve así:
Transfer-Encoding sobre Content-Length ⚠️
Entonces, ¿qué pasa si tenemos ambos headers en nuestro HTTP request? Ya existe un estándar para esto que define el comportamiento que la aplicación debería tomar:
💡 Si se recibe un mensaje con un campo de header Transfer-Encoding y un campo de header Content-Length, este último DEBE ser ignorado.
Para más información sobre esto, por favor referite al siguiente: RFC
Para resumir la idea, si un request contiene tanto un header CL como TE, el header TE tiene precedencia, y el header CL debería ser ignorado. ACÁ es cuando las cosas se empiezan a poner divertidas y mágicas.
Desincronización
Los ataques de request smuggling explotan discrepancias entre el reverse proxy y el web server (voy a ser repetitivo con esto, es la única forma de realmente entender la naturaleza de esta vulnerabilidad, perdón). En particular, el ataque fuerza un desacuerdo en los límites del request entre los dos sistemas, causando así una desincronización, razón por la cual los ataques de request smuggling a veces también se llaman Desync Attacks.
¿Pero qué se puede lograr con este desync?Generalmente hablando, existe la creencia de que los HTTP requests se ven de forma aislada y, por lo tanto, diferentes HTTP requests no pueden influenciarse entre sí PERO en realidad es todo lo contrario. Si la aplicación está siendo usada por muchos usuarios, hay una alta chance de influir en HTTP requests de terceros inyectando payloads maliciosos en ellos.
Ya que múltiples requests se envían por el mismo TCP stream como discutimos antes, un desacuerdo en los límites del request por diferentes sistemas (reverse proxy y backend server) le permite a un atacante lograr exactamente eso.
Cuando el reverse proxy y el web server no se ponen de acuerdo en los límites del HTTP request (TE o CL), ocurre una discrepancia detrás de escena que impacta el comienzo y el request subsiguiente, dejando datos en el TCP stream. Uno de los dos sistemas trata esto como un HTTP request parcial, mientras que el otro lo trata como parte del request anterior. Gracias a esto, un atacante puede manipular el siguiente HTTP request de un usuario real, obteniendo acceso a información sensible sobre el sistema y el usuario, o incluso haciendo cambios en nombre de otro usuario.
Dependiendo del tipo específico de desacuerdo entre los sistemas, las vulnerabilidades de HTTP request smuggling pueden tener diferentes impactos, incluyendo explotación masiva de XSS, robo de datos de otros usuarios y bypasses de WAF. Para más detalles sobre ataques de HTTP request smuggling, dale una mirada a este genial blog post de James Kettle.
Ataque CL.TE ⚔️
El tipo más común de desync attack es el CL.TE, que básicamente ocurre cuando un reverse proxy usa el Content-Length como referencia para el límite/boundary del HTTP request (en otras palabras, no soportando chunked encoding) mientras que el backend server hace lo mismo usando el Transfer-Encoding. Entonces, si el request tiene ambos headers, como el reverse proxy no soporta el TE, va a (incorrectamente) usar y tomar el CL en su lugar.
Interpretación del Reverse Proxy:
Primero miremos el request anterior desde la perspectiva del reverse proxy. Como el reverse proxy no soporta chunked encoding, usa el header CL para determinar la longitud del body del request. El header CL da la longitud como 10 bytes, lo que significa que el body del request se parsea como lo siguiente 0\r\n\r\nHELLO, por ejemplo:
Entonces en este caso, el web proxy está tomando el CL incluyendo 0 y HELLO en el body.
Interpretación del Web Server:
El web server correctamente prefiere el header TE sobre el header CL, como se define en el RFC mostrado en la sección anterior. Ya que el body del request en chunked encoding se termina con el chunk vacío de tamaño 0, el web server parsea el body del request como 0\r\n\r\n, por ejemplo:
Como se mencionó antes, chunked interpreta 0 como el final, así que HELLO va a ser agregado al siguiente request rompiendo el próximo HTTP method.
¡Así que hey! ¡Creamos nuestro primer desync attack! No fue tan difícil, ¿no? Pero, ¿qué fue exactamente lo que hicimos antes?...
Agregamos 'HELLO' al comienzo del siguiente X HTTP request, sea cual sea, rompiendo así el próximo request ya que se va a agregar a la primera palabra del siguiente request (el HTTP Method), rompiendo el próximo HTTP request al especificar un método inválido 'HELLOGET' o 'HELLOMETHOD'.
- El primer request va a resultar en un 200 OK con prácticamente ninguna información ya que enviamos un POST request sin ningún parámetro.
- La segunda respuesta va a ser un 405 Not Allowed ya que interrumpimos el siguiente request. Si otro usuario solicita un recurso del web server, ahora va a aparecer como HELLOGET. Como HELLOGET no es un HTTP method válido, interrumpimos el request, afectando el rendimiento de la aplicación web y generando desincronización entre diferentes sistemas.
Identificación del ataque CL.TE
Podemos aprovechar dos requests que deberíamos enviar en un corto período de tiempo entre sí, para poder emular la interacción de '2 usuarios diferentes'. Necesitamos hacer que nuestro primer request interfiera con el segundo.
En este ejemplo podemos ver cómo influimos y manipulamos exitosamente un HTTP request de un tercero.
Explotación de un ataque CL.TE
La explotación para aumentar la severidad del ataque está fuertemente relacionada con el entorno/aplicación web que estamos testeando, así que es dinámica y siempre está cambiando. Sin embargo, todavía podemos empezar con algo de reconocimiento, como obtener la información de /robots.txt.
En este módulo de HTB, nos enfrentamos a un desafío: obtener el valor del flag. Lamentablemente, no tenemos los privilegios de administrador requeridos para eso, así que necesitamos aplicar lo que aprendimos para lograrlo.
Como no tenemos acceso al flag, podemos intentar obligar al potencial admin a hacer el cambio por nosotros. Creando un desync attack donde inyectamos el endpoint que necesitamos para capturar lo que buscamos, podemos hacer lo siguiente:
En este caso, el request es chunked para el web server pero es procesado como CL por el reverse proxy, lo que significa que el reverse proxy va a forwardear todo el request como una unidad, y el backend server lo va a interpretar como dos requests diferentes. Esto entrega una respuesta para la parte chunked y toma el segundo header falso como el comienzo del siguiente request entrante. Así es como podemos engañar al sistema para que haga requests arbitrarios.
Entonces, si visitamos el endpoint /admin.php una vez más, vamos a ver el valor del flag sin enmascarar (no te preocupes por el flag, por suerte HTB rota los valores válidos).
Ataque TE.TE ⚔️
Este ejemplo, como podemos deducir, es sobre problemas de Transfer-Encoding y discrepancias entre el reverse proxy y el web server respecto a cómo soportan este header/directiva.
¿Entonces cómo puede haber algún problema si ambos soportan el mismo TE como forma de parsear los HTTP requests?Bueno... en realidad se trata más de qué sistema sigue el estándar RSA, mencionado anteriormente. Existe la posibilidad de que ambos sistemas acepten el TE pero solo uno aplique el estándar. Entonces, si manipulamos el request, podemos agregar un header Transfer-Encoding malicioso/incorrecto, forzando a uno de los dos sistemas a malinterpretar el request de la siguiente manera:
Identificación del ataque TE.TE
| Descripción | Header |
|---|---|
| Substring match | Transfer-Encoding: testchunked |
| Space in Header name | Transfer-Encoding : chunked |
| Horizontal Tab Separator | Transfer-Encoding:[\x09]chunked |
| Vertical Tab Separator | Transfer-Encoding:[\x0b]chunked |
| Leading space | Transfer-Encoding: chunked |
Para identificar una vulnerabilidad de request smuggling TE.TE, necesitamos engañar al reverse proxy o al web server para que ignore el header TE. Podemos hacer esto desviándonos ligeramente de la especificación para verificar si la implementación de los dos sistemas se adhiere a la especificación con precisión.
Por ejemplo, algunos sistemas podrían solo verificar la presencia de la keyword chunked en el header TE, mientras que otros sistemas requieren una coincidencia exacta. En tales casos, es suficiente con setear el header TE a testchunked para engañar a uno de los dos sistemas y hacer que ignore el header TE y vuelva al header CL en su lugar.
Nota: Las secuencias [\x09] y [\x0b] no son las secuencias de caracteres literales usadas en la ofuscación. Más bien denotan el carácter de tab horizontal (ASCII 0x09) y el carácter de tab vertical (ASCII 0x0b).Entonces podemos aprovechar este ataque cambiando el código hexadecimal como:
Si repetimos el mismo request vamos a encontrar el mensaje de HTTP Error Method:
💡 Los ataques de smuggling (excepto por client-side desync) deberían seguir funcionando incluso si incluís "Connection: close" en el request original, porque ese header solo afecta la conexión cliente-proxy , que no es la que se desincroniza.
La información anterior vino directamente de Martin Doyhenard quien, además de ser un excelente profesional, también es súper considerado y leyó mi blog post sobre su tema experto, "Request Smuggling". Detectó un error en el aspecto técnico del uso del header Connection para este tipo de ataques. Muchas gracias por tomarte el tiempo de leer el blog y hacérmelo saber.
Si querés ver algunos videos de él sobre estos temas específicos, considerá los siguientes videos:
- DEF CON 29 - Martin Doyhenard - Response Smuggling: Pwning HTTP 1 1 Connections (English)
- Response Smuggling: Exploiting HTTP/1.1 Connections ▪ Martin Doyhenard ▪ Ekoparty 2021 (Spanish)
Explotación del ataque TE.TE
Para este caso, el proceso es prácticamente el mismo. Una vez que identificamos el problema y el header payload que necesitamos construir, podemos ejecutar algo como esto para obtener el valor del flag del desafío:
Deberíamos ejecutar este payload algunas veces para esperar al request del "admin".
Ataque TE.CL ⚔️
Para enviar los requests mostrados en esta sección, necesitamos manipular el header CL. Para hacer esto en Burp Repeater, necesitamos instruir a Burp para que no actualice automáticamente el header CL. Además, necesitamos crear un tab group en Burp Repeater. Podemos agregar dos tabs de repeater a un tab group haciendo clic derecho en cualquier tab de request del repeater y seleccionando Add tag to group > Create tab group (tener múltiples requests en un tab group nos da la opción de enviar los requests en secuencia, lo cual es necesario para explotar el lab de abajo).
Identificación del ataque TE.CL
Este tipo de vulnerabilidad surge si el reverse proxy usa chunked encoding mientras que el web server usa el header CL. Considerá un request como el siguiente:
- Consideremos primero el request anterior desde la perspectiva del reverse proxy. El reverse proxy usa chunked encoding, por lo tanto parsea el body del request para que contenga un solo chunk con una longitud de 5 bytes, incluyendo '5\r\nHELLO\r\n0'.
- Como el web server usa el CL como límite para el parseo del HTTP request, va a tomar '3' como referencia, incluyendo solo el '5' y dejando el resto para el siguiente HTTP request en la cola.
Explotación y Ejercicio
Para este caso, necesitamos tomar el request a '/' y enviarlo al repeater dos veces, agregándolo al mismo grupo para enviar el request usando Send group (single connection). El primer tab va a contener el payload hacia el path filtrado por el WAF, y el segundo tab va a capturar la respuesta de '/admin'.
Tenemos dos líneas vacías en cada lugar: después del segundo Host y después del 0, porque así es como especificamos dónde termina el header y dónde comienza el payload. Necesitamos considerar eso al especificar el tamaño del chunk, que es 32 para este caso.
Entonces, este segundo tab va a recibir la respuesta del request chunked que enviamos en el primer tab.
Algo importante es que necesitamos cambiar de 'chunked' y emplear la misma técnica que usamos antes. Para obtener el valor del flag, podemos en su lugar usar 'testchunked', que va a ser efectivo.
Para obtener este flag el request necesita usar testchunked o whateverchunked...
Software Vulnerable
Hasta ahora, notamos problemas de request smuggling causados por un parseo defectuoso o falta de soporte para el header TE. Sin embargo, los web servers o reverse proxies también pueden ser vulnerables a request smuggling debido a otros problemas que causan que la longitud de un request se procese incorrectamente...
En este lab, vamos a explotar una vulnerabilidad en el HTTP Gunicorn web server que fue detallada en este blog post. Gunicorn 20.0.4 contenía un bug al encontrar el HTTP header Sec-Websocket-Key1 que fijaba el body del request a una longitud de 8 bytes, sin importar los valores seteados para los headers CL y TE. Este es un header especial usado en el establecimiento de conexiones WebSocket. Como el reverse proxy no sufre de este bug, esto nos permite crear una desincronización entre los dos sistemas.
Identificación del Gunicorn 20.0.4
Entonces, ¿cómo procesa el backend server estos requests? Como podríamos esperar, el reverse proxy simplemente usa el CL, forwardeando todo al backend. Luego, el backend parsea el header Sec-WebSocket-Key1 en vez de usar el CL, asumiendo un body de 8 bytes.
Siempre son 8 bytes, ni más ni menos. ¡Dale una mirada al código!
Entonces el backend server toma primero 8 bytes, luego un segundo request y responde ese request en el tercero.
Explotación del Gunicorn 20.0.4 y desafío
Explotación de Request Smuggling
En las instancias anteriores, exploramos varios tipos de ataques de HTTP request smuggling y cómo detectarlos. Ahora vamos a explorar varios métodos para explotar ataques de request smuggling. Las vulnerabilidades de HTTP request smuggling tienen un impacto alto porque permiten a los atacantes bypassear controles de seguridad como WAFs, forzar a otros usuarios a realizar acciones autenticadas, capturar datos personales de otros usuarios, y robar sus sesiones para tomar control de cuentas y explotar masivamente vulnerabilidades de reflected XSS.
Entonces, vamos a explorar tres formas diferentes de explotar esta vulnerabilidad. Primero, vamos al bypass de WAF, después vamos a ver cómo robar datos de usuarios usando un POST request para escribir comentarios en un sitio web, y... por último pero no menos importante, HTB muestra en esta sección cómo un XSS masivo + HTTP Desync puede funcionar cuando se combinan 🤩🤩 (bonus de diversión).
El desafío esta vez trata de explotar HTTP request smuggling para forzar a un usuario a ingresar sus credenciales en la sección de comentarios.
Desafío
Entonces, empezamos haciendo algunas pruebas solo para determinar qué tipo de HTTP Desync estamos enfrentando. Para este caso, y después de varios intentos, sabemos que es CL-TE, lo que significa que el web proxy está tomando el Content-Length para parsear el request, pero el backend server está tomando el Transfer-Encoding en su lugar. Esto significa que en el mismo test1 (repeater group con una single connection), obtenemos el 200 OK para el primer request y 405 Not Allowed para el segundo, ya que el backend server está agregando 'HELLO' como la primera línea para el siguiente request, convirtiendo GET en HELLOGET... (method not allowed).
El ataque
Entonces, después de haber descubierto el problema, NECESITAMOS empezar a entender CÓMO activamos esa funcionalidad.
Pasé mucho tiempo probando cosas sin primero confirmarlas, así que no pierdas tu mentalidad hacker; primero entendé, después atacá, y finalmente, disfrutá.
Entonces, para hacerlo de la manera más eficiente posible, necesitamos pensar en las restricciones que existen para lograr que ese 'comment request' funcione. Para este caso particular, verificamos que necesitamos un valor de Cookie (estar autenticado) + el CSRF token de ese usuario; de lo contrario, tampoco podés usar el CSRF para un usuario no autenticado...
Este request está bastante bien pero no es suficiente... No estoy seguro de por qué necesitamos proveer el header Content-Type como la funcionalidad principal/request real para que esto funcione.
💡 IMPORTANTE: Podemos validar qué tipo de HTTP request smuggling tenemos, si es que tenemos uno, sin usar ningún tipo de header extra. Solo con la primera línea, host, TE y CL, estamos bien. Para explotar una funcionalidad específica, NECESITAMOS mantener todos los headers del request real, solo para evitar cualquier problema con cómo funcionan las aplicaciones web para ese request/funcionalidad específica.
Entonces ahora, sabemos que la primera sección activa el HTTP request smuggling (lo usamos antes para validar el problema). Ahora el payload debería contener para este caso TAMBIÉN el Content-Type + la Cookie + el csrf de ese usuario (nuestro usuario).
Finalmente obtuvimos el valor del usuario admin:
💡 Algo que noté, es que estaba copiando y pegando solo el valor de la cookie, así que en mi caso estaba intentando acceder al panel de admin usando "Cookie: PHPSESSID:fd1dt4khy36dthmc" y debería usar "Cookie: session=fd1dt4khy36dthmc" (ya sé, es tonto pero vale la pena contártelo).
SIMPLEMENTE TENÉ CUIDADO CON ESTOS DETALLES
Herramientas y Prevención de Request Smuggling
Una herramienta útil para ayudarnos en la identificación y explotación de vulnerabilidades de HTTP request smuggling es la extensión de Burp HTTP Request Smuggler. Podemos instalarla desde la Burp Extensions Store en la pestaña Extensions. Andá a BApp Store e instalá la extensión desde ahí.
💡 Esta sección tiene buenas configuraciones automatizadas para buscar esta vulnerabilidad de una manera más automatizada. Vale la pena darle una mirada, pero no creo que valga la pena seguir agregando más información sobre automatización en este post.
Mitigaciones y pasos recomendados
Prevenir ataques de HTTP request smuggling generalmente no es tarea fácil, ya que los problemas que causan las vulnerabilidades de request smuggling muchas veces residen dentro del software del web server en sí. Por lo tanto, no pueden ser prevenidos desde dentro de la aplicación web. Además, los desarrolladores de aplicaciones web podrían desconocer las particularidades subyacentes del web server, que podrían llevar a vulnerabilidades de HTTP request smuggling, de tal manera que no tienen chance de prevenirlas. Sin embargo, hay algunas recomendaciones generales que podemos seguir al configurar nuestro setup de deploy para asegurar que el riesgo de vulnerabilidades de HTTP request smuggling sea lo más mínimo posible, o al menos que el impacto se reduzca:
- Asegurate de que el software del web server y reverse proxy se mantenga actualizado para que los parches de seguridad se instalen lo antes posible
- Asegurate de que las vulnerabilidades del lado del cliente que puedan parecer inexplotables por sí solas se parcheen igualmente, ya que podrían volverse explotables en un escenario de HTTP request smuggling
- Asegurate de que el comportamiento por defecto del web server sea cerrar las conexiones TCP si ocurre cualquier excepción o error a nivel del web server durante el manejo o parseo del request
- Si es posible, configurá el uso de HTTP/2 entre el cliente y el web server y asegurate de que las versiones HTTP más antiguas estén deshabilitadas. Vamos a discutir en las próximas secciones por qué esto es beneficioso
La mayoría de estos ejemplos/ejercicios fueron extraídos del módulo 'HTTP Attacks' (CRLF Injection, HTTP Desync y HTTP/2 Downgrading) de HTB.
Path: Senior Web Penetration Tester
Exam: Certified Web Exploitation Expert (CWEE)
Difficulty: Hard
Tier: III
Module Author: vautia
Pon a Prueba tu Conocimiento Técnico
Repaso de HTTP Request Smuggling
Si una request HTTP contiene tanto Transfer-Encoding como Content-Length, ¿qué header debería tener prioridad según el estándar citado en el post?
¿Qué quiere decir el post con una desynchronization en request smuggling?
¿Por qué esa desynchronization puede volverse tan peligrosa en aplicaciones reales?
Seguir leyendo
Más en el archivo
Artículo más reciente
Curso de Introducción a la Seguridad en IA por Lakera AI
Sumergite en los fundamentos de la seguridad en IA y aprendé sobre el panorama de amenazas de IA y cómo proteger Modelos de Lenguaje Grande (LLMs) con este curso introductorio gratuito de 10 días.
Artículo anterior
Atacando LLMs - OWASP Top 10 (Parte 1)
Descubrí las complejidades de las vulnerabilidades de los Modelos de Lenguaje Grande con insights sobre estrategias de mitigación para mantener tus sistemas de IA seguros.