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

2025-10-10 18:36:50 +00:00 · 2025-09-05 11:33:10 +00:00 · 2025-09-05 11:33:10 +00:00 · dc153a2acf
commit dc153a2acf
parent 5ef3bcbef3
1 changed files with 179 additions and 181 deletions
--- a/src/pentesting-web/http-request-smuggling/README.md
+++ b/src/pentesting-web/http-request-smuggling/README.md
@ -5,8 +5,8 @@

 ## O que é

-Esta vulnerabilidade ocorre quando uma **dessincronização** entre os **front-end proxies** e o servidor **back-end** permite que um **attacker** **envie** uma HTTP **request** que será **interpretada** como uma **única request** pelos **front-end** (load balance/reverse-proxy) e **como 2 requests** pelo servidor **back-end**.\
-Isso permite que um usuário **modifique a próxima request que chegar ao servidor back-end após a dele**.
+Esta vulnerabilidade ocorre quando uma **dessincronização** entre **front-end proxies** e o **back-end** permite que um **atacante** **envie** uma **requisição** HTTP que será **interpretada** como **uma única requisição** pelos **front-end** (load balance/reverse-proxy) e **como 2 requisições** pelo **servidor de back-end**.\
+Isso permite que um usuário **modifique a próxima requisição que chegar ao back-end depois da sua**.

 ### Teoria

@ -25,57 +25,57 @@ Isso permite que um usuário **modifique a próxima request que chegar ao servid

 ### Realidade

-O **Front-End** (um load-balance / Reverse Proxy) **processa** o cabeçalho _**Content-Length**_ ou o _**Transfer-Encoding**_ e o servidor **Back-end** **processa o outro**, provocando uma **dessincronização** entre os 2 sistemas.\
-Isto pode ser muito crítico, pois **um attacker poderá enviar uma request** ao reverse proxy que será **interpretada** pelo servidor **back-end** **como 2 requests diferentes**. O **perigo** desta técnica reside no fato de que o **back-end** irá interpretar a **2ª request injetada** como se ela **viesse do próximo cliente** e a **request real** desse cliente fará **parte** da **request injetada**.
+O **Front-End** (um load-balance / Reverse Proxy) **processa** o cabeçalho _**Content-Length**_ ou o _**Transfer-Encoding**_ e o **Back-end** processa o outro, provocando uma **dessincronização** entre os 2 sistemas.\
+Isto pode ser muito crítico, pois **um atacante poderá enviar uma requisição** ao reverse proxy que será **interpretada** pelo **back-end** **como 2 requisições diferentes**. O **perigo** desta técnica reside no fato de que o **back-end** irá interpretar a **2ª requisição injetada** como se ela **tivesse vindo do próximo cliente** e a **requisição real** desse cliente fará **parte** da **requisição injetada**.

 ### Particularidades

-Lembre-se que em HTTP **um caractere de new line é composto por 2 bytes:**
+Lembre-se que em HTTP **um caractere de nova linha é composto por 2 bytes:**

- **Content-Length**: Este header usa um **número decimal** para indicar o **número** de **bytes** do **body** da request. Espera-se que o body termine no último caractere; **uma new line não é necessária no fim da request**.
- **Transfer-Encoding:** Este header usa no **body** um **número hexadecimal** para indicar o **número** de **bytes** do **próximo chunk**. O **chunk** deve **terminar** com uma **new line**, mas essa new line **não é contada** pelo indicador de tamanho. Este método de transferência deve terminar com um **chunk de tamanho 0 seguido por 2 new lines**: `0`
- **Connection**: Pela minha experiência, é recomendado usar **`Connection: keep-alive`** na primeira request do Request Smuggling.
+- **Content-Length**: Este cabeçalho usa um **número decimal** para indicar o **número** de **bytes** do **body** da requisição. O corpo espera-se terminar no último caractere; **uma nova linha não é necessária no final da requisição**.
+- **Transfer-Encoding:** Este cabeçalho usa no **body** um **número hexadecimal** para indicar o **número** de **bytes** do **próximo chunk**. O **chunk** deve **terminar** com uma **nova linha**, mas essa nova linha **não é contada** pelo indicador de tamanho. Este método de transferência deve terminar com um **chunk de tamanho 0 seguido de 2 novas linhas**: `0`
+- **Connection**: Pela minha experiência, é recomendado usar **`Connection: keep-alive`** na primeira requisição do Request Smuggling.

 ### Visible - Hidden

-O principal problema com HTTP/1.1 é que todas as requests usam o mesmo socket TCP, então se uma discrepância for encontrada entre 2 sistemas que recebem requests, é possível enviar uma request que será tratada como 2 requests diferentes (ou mais) pelo backend final (ou até por sistemas intermediários).
+O problema principal com http/1.1 é que todas as requisições seguem pelo mesmo socket TCP, então se for encontrada uma discrepância entre 2 sistemas que recebem requisições é possível enviar uma requisição que será tratada como 2 requisições diferentes (ou mais) pelo backend final (ou até por sistemas intermediários).

-[This blog post](https://portswigger.net/research/http1-must-die) propõe novas formas de detectar desync attacks num sistema que não serão sinalizadas por WAFs. Para isso apresenta os comportamentos Visible vs Hidden. O objetivo aqui é tentar encontrar discrepâncias nas respostas usando técnicas que poderiam estar causando desyncs sem realmente explorar nada.
+[This blog post](https://portswigger.net/research/http1-must-die) propõe novas formas de detectar ataques de desync a um sistema que não serão sinalizados por WAFs. Para isso ela apresenta os comportamentos Visible vs Hidden. O objetivo neste caso é tentar encontrar discrepâncias nas respostas usando técnicas que possam estar causando desyncs sem realmente explorar nada.

-Por exemplo, enviar uma request com o cabeçalho normal Host e um cabeçalho " host", se o backend reclamar sobre essa request (talvez porque o valor de " host" está incorreto) isso pode significar que o front-end não levou em conta o cabeçalho " host" enquanto o backend final sim, implicando uma forte probabilidade de dessincronização entre front-end e backend.
+Por exemplo, enviar uma requisição com o header normal Host e um header " host" (com espaço) — se o backend reclamar sobre essa requisição (talvez porque o valor de " host" esteja incorreto) isso pode significar que o front-end não viu o header " host" enquanto o backend final o utilizou, altamente provável implicando uma dessincronização entre front-end e backend.

 Isto seria uma discrepância **Hidden-Visible**.

-Se o front-end tivesse levado em conta o cabeçalho " host" mas o back-end não, isso poderia ser uma situação **Visible-Hidden**.
+Se o front-end tivesse levado em conta o header " host" mas o backend não, isso poderia ser uma situação **Visible-Hidden**.

-Por exemplo, isso permitiu descobrir desyncs entre AWS ALB como front-end e IIS como backend. Isso ocorreu porque quando o "Host: foo/bar" foi enviado, o ALB retornou `400, Server; awselb/2.0`, mas quando "Host : foo/bar" foi enviado, retornou `400, Server: Microsoft-HTTPAPI/2.0`, indicando que o backend estava enviando a resposta. Isto é uma situação Hidden-Visible (H-V).
+Por exemplo, isso permitiu descobrir desyncs entre AWS ALB como front-end e IIS como backend. Isso aconteceu porque quando "Host: foo/bar" foi enviado, o ALB retornou `400, Server; awselb/2.0`, mas quando "Host : foo/bar" foi enviado, retornou `400, Server: Microsoft-HTTPAPI/2.0`, indicando que o backend estava enviando a resposta. Esta é uma situação Hidden-Visible (H-V).

-Note que esta situação não é corrigida pela AWS, mas pode ser prevenida configurando `routing.http.drop_invalid_header_fields.enabled` e `routing.http.desync_mitigation_mode = strictest`.
+Note que esta situação não está corrigida na AWS, mas pode ser prevenida configurando `routing.http.drop_invalid_header_fields.enabled` e `routing.http.desync_mitigation_mode = strictest`.


 ## Exemplos Básicos

 > [!TIP]
-> Ao tentar explorar isso com Burp Suite **desative `Update Content-Length` e `Normalize HTTP/1 line endings`** no Repeater porque alguns gadgets abusam de newlines, carriage returns e Content-Lengths malformados.
+> Ao tentar explorar isso com Burp Suite **desative `Update Content-Length` e `Normalize HTTP/1 line endings`** no repeater porque alguns gadgets abusam de newlines, carriage returns e content-lengths malformados.

-HTTP request smuggling attacks são criadas enviando requests ambíguas que exploram discrepâncias em como front-end e back-end interpretam os headers `Content-Length` (CL) e `Transfer-Encoding` (TE). Esses ataques podem se manifestar de diferentes formas, principalmente como **CL.TE**, **TE.CL** e **TE.TE**. Cada tipo representa uma combinação diferente de como os servidores front-end e back-end priorizam esses headers. As vulnerabilidades surgem quando os servidores processam a mesma request de maneiras diferentes, levando a resultados inesperados e potencialmente maliciosos.
+Os ataques de HTTP request smuggling são criados enviando requisições ambíguas que exploram discrepâncias em como front-end e back-end interpretam os cabeçalhos `Content-Length` (CL) e `Transfer-Encoding` (TE). Esses ataques podem se manifestar de diferentes formas, principalmente como **CL.TE**, **TE.CL** e **TE.TE**. Cada tipo representa uma combinação única de como os servidores front-end e back-end priorizam esses cabeçalhos. As vulnerabilidades surgem quando os servidores processam a mesma requisição de maneiras diferentes, levando a resultados inesperados e potencialmente maliciosos.

 ### Exemplos Básicos de Tipos de Vulnerabilidade

 ![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)

 > [!TIP]
-> Ao arquivo anterior você deve adicionar a técnica TE.0, semelhante à técnica CL.0 mas usando Transfer-Encoding.
+> À tabela anterior você deve adicionar a técnica TE.0, similar à técnica CL.0 mas usando Transfer-Encoding.

-#### CL.TE Vulnerability (Content-Length usado pelo Front-End, Transfer-Encoding usado pelo Back-End)
+#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)

- **Front-End (CL):** Processa a request com base no header `Content-Length`.
- **Back-End (TE):** Processa a request com base no header `Transfer-Encoding`.
- **Cenário de ataque:**
+- **Front-End (CL):** Processa a requisição com base no cabeçalho `Content-Length`.
+- **Back-End (TE):** Processa a requisição com base no cabeçalho `Transfer-Encoding`.
+- **Cenário de Ataque:**

- O atacante envia uma request onde o valor do header `Content-Length` não corresponde ao comprimento real do conteúdo.
- O servidor front-end encaminha a request inteira para o back-end, com base no valor de `Content-Length`.
- O servidor back-end processa a request como chunked devido ao header `Transfer-Encoding: chunked`, interpretando os dados restantes como uma request subsequente separada.
+- O atacante envia uma requisição onde o valor do cabeçalho `Content-Length` não corresponde ao tamanho real do conteúdo.
+- O front-end encaminha toda a requisição ao back-end, com base no valor de `Content-Length`.
+- O back-end processa a requisição como chunked devido ao cabeçalho `Transfer-Encoding: chunked`, interpretando os dados restantes como uma requisição subsequente separada.
 - **Exemplo:**

 ```
@ -91,15 +91,15 @@ GET /404 HTTP/1.1
 Foo: x
 ```

-#### TE.CL Vulnerability (Transfer-Encoding usado pelo Front-End, Content-Length usado pelo Back-End)
+#### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)

- **Front-End (TE):** Processa a request com base no header `Transfer-Encoding`.
- **Back-End (CL):** Processa a request com base no header `Content-Length`.
- **Cenário de ataque:**
+- **Front-End (TE):** Processa a requisição com base no cabeçalho `Transfer-Encoding`.
+- **Back-End (CL):** Processa a requisição com base no cabeçalho `Content-Length`.
+- **Cenário de Ataque:**

- O atacante envia uma request chunked onde o tamanho do chunk (`7b`) e o comprimento real do conteúdo (`Content-Length: 4`) não coincidem.
- O front-end, respeitando `Transfer-Encoding`, encaminha a request inteira para o back-end.
- O back-end, respeitando `Content-Length`, processa apenas a parte inicial da request (os `7b` bytes), deixando o restante como parte de uma request subsequente não intencional.
+- O atacante envia uma requisição chunked onde o tamanho do chunk (`7b`) e o comprimento real do conteúdo (`Content-Length: 4`) não coincidem.
+- O front-end, honrando `Transfer-Encoding`, encaminha a requisição inteira ao back-end.
+- O back-end, respeitando `Content-Length`, processa apenas a parte inicial da requisição (`7b` bytes), deixando o restante como parte de uma requisição subsequente não intencional.
 - **Exemplo:**

 ```
@ -120,14 +120,14 @@ x=

 ```

-#### TE.TE Vulnerability (Transfer-Encoding usado por ambos, com obfuscação)
+#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)

 - **Servidores:** Ambos suportam `Transfer-Encoding`, mas um pode ser enganado a ignorá-lo via obfuscação.
- **Cenário de ataque:**
+- **Cenário de Ataque:**

- O atacante envia uma request com headers `Transfer-Encoding` obfuscados.
- Dependendo de qual servidor (front-end ou back-end) falhar ao reconhecer a obfuscação, uma vulnerabilidade CL.TE ou TE.CL pode ser explorada.
- A parte não processada da request, como vista por um dos servidores, torna-se parte de uma request subsequente, levando ao smuggling.
+- O atacante envia uma requisição com cabeçalhos `Transfer-Encoding` obfuscados.
+- Dependendo de qual servidor (front-end ou back-end) falha em reconhecer a obfuscação, uma vulnerabilidade CL.TE ou TE.CL pode ser explorada.
+- A parte não processada da requisição, como vista por um dos servidores, torna-se parte de uma requisição subsequente, levando ao smuggling.
 - **Exemplo:**

 ```
@ -147,10 +147,10 @@ Transfer-Encoding
 : chunked
 ```

-#### **CL.CL Scenario (Content-Length usado por ambos Front-End e Back-End)**
+#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**

- Ambos os servidores processam a request baseados exclusivamente no header `Content-Length`.
- Este cenário tipicamente não leva ao smuggling, pois há alinhamento em como ambos interpretam o comprimento da request.
+- Ambos os servidores processam a requisição baseado exclusivamente no cabeçalho `Content-Length`.
+- Este cenário tipicamente não leva a smuggling, pois há alinhamento em como ambos os servidores interpretam o tamanho da requisição.
 - **Exemplo:**

 ```
@ -164,8 +164,8 @@ Normal Request

 #### **CL.0 Scenario**

- Refere-se a cenários onde o header `Content-Length` está presente e tem um valor diferente de zero, indicando que o body da request tem conteúdo. O back-end ignora o header `Content-Length` (que é tratado como 0), mas o front-end o analisa.
- É crucial para entender e construir ataques de smuggling, já que influencia como os servidores determinam o fim de uma request.
+- Refere-se a cenários onde o cabeçalho `Content-Length` está presente e tem um valor diferente de zero, indicando que o corpo da requisição tem conteúdo. O back-end ignora o cabeçalho `Content-Length` (tratado como 0), mas o front-end o parseia.
+- É crucial para entender e construir ataques de smuggling, pois influencia como os servidores determinam o fim de uma requisição.
 - **Exemplo:**

 ```
@ -179,9 +179,9 @@ Non-Empty Body

 #### TE.0 Scenario

- Igual ao anterior, mas usando TE
+- Igual ao anterior, mas usando TE.
 - Técnica [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
- **Example**:
+- **Exemplo**:
 ```
 OPTIONS / HTTP/1.1
 Host: {HOST}
@ -201,7 +201,7 @@ EMPTY_LINE_HERE
 ```
 #### `0.CL` Cenário

-Em um cenário `0.CL`, uma requisição é enviada com um Content-Length como:
+Em uma situação `0.CL`, uma requisição é enviada com um Content-Length como:
 ```
 GET /Logon HTTP/1.1
 Host: <redacted>
@ -211,42 +211,42 @@ Content-Length:
 GET /404 HTTP/1.1
 X: Y
 ```
-E o front-end não leva o `Content-Length` em conta, então ele envia apenas a primeira request para o backend (até o 7 no exemplo). No entanto, o backend vê o `Content-Length` e espera por um body que nunca chega, porque o front-end já está aguardando pela response.
+E o front-end não leva em conta o `Content-Length`, então ele envia apenas a primeira request para o backend (até o 7 no exemplo). Entretanto, o backend vê o `Content-Length` e fica esperando por um body que nunca chega, pois o front-end já está aguardando a resposta.

-Porém, se existir uma request que possa ser enviada ao backend e que seja respondida antes de receber o body da request, esse deadlock não ocorrerá. No IIS, por exemplo, isso acontece ao enviar requests para palavras proibidas como `/con` (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), dessa forma a request inicial será respondida diretamente e a segunda request conterá a request da vítima como:
+Porém, se existir uma request que possa ser enviada ao backend e que seja respondida antes do recebimento do body, esse deadlock não ocorrerá. Em IIS, por exemplo, isso acontece ao enviar requests para palavras proibidas como `/con` (veja a [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), dessa forma a request inicial será respondida diretamente e a segunda request conterá a request da vítima como:
 ```
 GET / HTTP/1.1
 X: yGET /victim HTTP/1.1
 Host: <redacted>
 ```
-Isso é útil para causar um desync, mas não terá qualquer impacto até agora.
+Isto é útil para causar uma desync, mas até agora não teve qualquer impacto.

 However, the post offers a solution for this by converting a **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.

 #### Quebrando o servidor web

-Esta técnica também é útil em cenários onde é possível **break a web server while reading the initial HTTP data** mas **without closing the connection**. Dessa forma, o **body** of the HTTP request será considerado a **next HTTP request**.
+Esta técnica também é útil em cenários onde é possível **quebrar um servidor web enquanto lê os dados HTTP iniciais** mas **sem fechar a conexão**. Desta forma, o **corpo** da requisição HTTP será considerado como a **próxima requisição HTTP**.

-Por exemplo, como explicado em [**this writeup**](https://mizu.re/post/twisty-python), In Werkzeug era possível enviar alguns **Unicode** characters e isso fará o servidor **break**. However, if the HTTP connection was created with the header **`Connection: keep-alive`**, the body of the request won’t be read and the connection will still be open, so the **body** of the request will be treated as the **next HTTP request**.
+For example, as explained in [**this writeup**](https://mizu.re/post/twisty-python), In Werkzeug it was possible to send some **Unicode** characters and it will make the server **break**. However, if the HTTP connection was created with the header **`Connection: keep-alive`**, the body of the request won’t be read and the connection will still be open, so the **body** of the request will be treated as the **next HTTP request**.

 #### Forçando via hop-by-hop headers

-Abusando de hop-by-hop headers você poderia indicar ao proxy para **delete the header Content-Length or Transfer-Encoding so a HTTP request smuggling is possible to abuse**.
+Abusando de hop-by-hop headers você pode indicar ao proxy para **deletar o cabeçalho Content-Length ou Transfer-Encoding, permitindo assim que um HTTP request smuggling seja explorado**.
 ```
 Connection: Content-Length
 ```
-Para **mais informações sobre hop-by-hop headers** visite:
+For **more information about hop-by-hop headers** visit:


 {{#ref}}
 ../abusing-hop-by-hop-headers.md
 {{#endref}}

-## Finding HTTP Request Smuggling
+## Encontrando HTTP Request Smuggling

-Identificar vulnerabilidades de HTTP request smuggling frequentemente pode ser feito usando técnicas de temporização, que dependem de observar quanto tempo o servidor demora a responder a requisições manipuladas. Essas técnicas são particularmente úteis para detectar vulnerabilidades CL.TE e TE.CL. Além desses métodos, existem outras estratégias e ferramentas que podem ser usadas para encontrar tais vulnerabilidades:
+Identificar vulnerabilidades de HTTP request smuggling pode frequentemente ser feito usando técnicas de temporização, que se baseiam em observar quanto tempo o servidor demora a responder a requisições manipuladas. Essas técnicas são particularmente úteis para detectar vulnerabilidades CL.TE e TE.CL. Além desses métodos, existem outras estratégias e ferramentas que podem ser usadas para encontrar tais vulnerabilidades:

-### Finding CL.TE Vulnerabilities Using Timing Techniques
+### Encontrando vulnerabilidades CL.TE usando técnicas de temporização

 - **Método:**

@ -266,14 +266,14 @@ A
 ```

 - **Observação:**
- O servidor front-end processa a requisição com base em `Content-Length` e corta a mensagem prematuramente.
- O servidor back-end, esperando uma mensagem chunked, aguarda pelo próximo chunk que nunca chega, causando um atraso.
+- O servidor front-end processa a requisição com base no `Content-Length` e corta a mensagem prematuramente.
+- O servidor back-end, esperando uma mensagem chunked, aguarda o próximo chunk que nunca chega, causando um atraso.

 - **Indicadores:**
- Time-outs ou longos atrasos na resposta.
- Receber um 400 Bad Request do servidor back-end, às vezes com informações detalhadas do servidor.
+- Timeouts ou longos atrasos na resposta.
+- Receber um erro 400 Bad Request do servidor back-end, às vezes com informações detalhadas do servidor.

-### Finding TE.CL Vulnerabilities Using Timing Techniques
+### Encontrando vulnerabilidades TE.CL usando técnicas de temporização

 - **Método:**

@ -292,23 +292,23 @@ X
 ```

 - **Observação:**
- O servidor front-end processa a requisição com base em `Transfer-Encoding` e encaminha a mensagem inteira.
- O servidor back-end, esperando uma mensagem baseada em `Content-Length`, aguarda por dados adicionais que nunca chegam, causando um atraso.
+- O servidor front-end processa a requisição com base no `Transfer-Encoding` e encaminha toda a mensagem.
+- O servidor back-end, esperando uma mensagem baseada em `Content-Length`, aguarda dados adicionais que nunca chegam, causando um atraso.

-### Other Methods to Find Vulnerabilities
+### Outros métodos para encontrar vulnerabilidades

- **Differential Response Analysis:**
- Envie versões ligeiramente variadas de uma requisição e observe se as respostas do servidor diferem de forma inesperada, indicando uma discrepância de parsing.
- **Using Automated Tools:**
+- **Análise de Resposta Diferencial:**
+- Envie versões ligeiramente diferentes de uma requisição e observe se as respostas do servidor diferem de forma inesperada, indicando uma discrepância no processamento.
+- **Uso de ferramentas automatizadas:**
 - Ferramentas como a extensão 'HTTP Request Smuggler' do Burp Suite podem testar automaticamente essas vulnerabilidades enviando várias formas de requisições ambíguas e analisando as respostas.
- **Content-Length Variance Tests:**
- Envie requisições com valores de `Content-Length` variando e que não correspondem ao tamanho real do conteúdo e observe como o servidor lida com essas discrepâncias.
- **Transfer-Encoding Variance Tests:**
- Envie requisições com cabeçalhos `Transfer-Encoding` ofuscados ou malformados e monitore como front-end e back-end respondem de maneira diferente a essas manipulações.
+- **Testes de variação de Content-Length:**
+- Envie requisições com valores variados de `Content-Length` que não correspondem ao comprimento real do conteúdo e observe como o servidor lida com essas incompatibilidades.
+- **Testes de variação de Transfer-Encoding:**
+- Envie requisições com cabeçalhos `Transfer-Encoding` ofuscados ou malformados e monitore como os servidores front-end e back-end respondem de maneira diferente a essas manipulações.

 ### The `Expect: 100-continue` header

-Veja como esse header pode ajudar a explorar um http desync em:
+Confira como esse cabeçalho pode ajudar a explorar um http desync em:

 {{#ref}}
 ../../network-services-pentesting/pentesting-web/special-http-headers.md
@ -316,25 +316,25 @@ Veja como esse header pode ajudar a explorar um http desync em:

 ### HTTP Request Smuggling Vulnerability Testing

-Após confirmar a efetividade das técnicas de temporização, é crucial verificar se requisições de clientes podem ser manipuladas. Um método simples é tentar envenenar suas requisições, por exemplo, fazer uma requisição a `/` retornar um 404. Os exemplos `CL.TE` e `TE.CL` discutidos anteriormente em [Basic Examples](#basic-examples) demonstram como envenenar a requisição de um cliente para provocar um 404, apesar de o cliente tentar acessar um recurso diferente.
+Depois de confirmar a eficácia das técnicas de temporização, é crucial verificar se as requisições do cliente podem ser manipuladas. Um método simples é tentar envenenar suas requisições, por exemplo, fazendo com que uma requisição para `/` retorne 404. Os exemplos `CL.TE` e `TE.CL` discutidos anteriormente em [Basic Examples](#basic-examples) demonstram como envenenar a requisição de um cliente para provocar um 404, apesar do cliente tentar acessar outro recurso.

-**Key Considerations**
+**Considerações-chave**

-Ao testar request smuggling interferindo em outras requisições, tenha em mente:
+Ao testar request smuggling interferindo com outras requisições, tenha em mente:

- **Distinct Network Connections:** As requisições "attack" e "normal" devem ser enviadas por conexões de rede distintas. Usar a mesma conexão para ambas não valida a presença da vulnerabilidade.
- **Consistent URL and Parameters:** Procure usar URLs idênticas e os mesmos nomes de parâmetros para ambas as requisições. Aplicações modernas frequentemente roteiam requisições para servidores back-end específicos com base na URL e nos parâmetros. Casá-las aumenta a probabilidade de que ambas sejam processadas pelo mesmo servidor, requisito para um ataque bem-sucedido.
- **Timing and Racing Conditions:** A requisição "normal", destinada a detectar interferência da requisição "attack", compete com outras requisições concorrentes da aplicação. Portanto, envie a requisição "normal" imediatamente após a "attack". Aplicações muito ocupadas podem exigir várias tentativas para confirmação conclusiva da vulnerabilidade.
- **Load Balancing Challenges:** Servidores front-end atuando como load balancers podem distribuir requisições entre vários sistemas back-end. Se as requisições "attack" e "normal" caírem em sistemas diferentes, o ataque não terá sucesso. Esse aspecto de balanceamento pode exigir várias tentativas para confirmar uma vulnerabilidade.
- **Unintended User Impact:** Se seu ataque afetar inadvertidamente a requisição de outro usuário (não a requisição "normal" que você enviou para detecção), isso indica que seu ataque influenciou outro usuário da aplicação. Testes contínuos podem atrapalhar outros usuários, exigindo uma abordagem cautelosa.
+- **Conexões de rede distintas:** As requisições "attack" e "normal" devem ser enviadas por conexões de rede separadas. Utilizar a mesma conexão para ambas não valida a presença da vulnerabilidade.
+- **URL e parâmetros consistentes:** Procure usar URLs idênticas e os mesmos nomes de parâmetros para ambas as requisições. Aplicações modernas frequentemente direcionam requisições para servidores back-end específicos com base na URL e parâmetros. Igualar esses valores aumenta a probabilidade de que ambas as requisições sejam processadas pelo mesmo servidor, um pré-requisito para um ataque bem-sucedido.
+- **Tempos e condições de corrida:** A requisição "normal", destinada a detectar interferência da requisição "attack", compete com outras requisições concorrentes da aplicação. Portanto, envie a requisição "normal" imediatamente após a requisição "attack". Aplicações muito ativas podem exigir várias tentativas para confirmação conclusiva da vulnerabilidade.
+- **Desafios de balanceamento de carga:** Servidores front-end que atuam como balanceadores de carga podem distribuir requisições entre vários sistemas back-end. Se as requisições "attack" e "normal" forem para sistemas diferentes, o ataque não terá sucesso. Esse aspecto de balanceamento pode exigir várias tentativas para confirmar uma vulnerabilidade.
+- **Impacto involuntário em usuários:** Se seu ataque afetar inadvertidamente a requisição de outro usuário (não a requisição "normal" que você enviou para detecção), isso indica que seu ataque influenciou outro usuário da aplicação. Testes contínuos podem interromper outros usuários, exigindo uma abordagem cautelosa.

-## Distinguishing HTTP/1.1 pipelining artifacts vs genuine request smuggling
+## Distinguindo artefatos de pipelining HTTP/1.1 vs genuine request smuggling

-Connection reuse (keep-alive) e pipelining podem facilmente produzir ilusões de "smuggling" em ferramentas de teste que enviam múltiplas requisições no mesmo socket. Aprenda a separar artefatos inofensivos do lado do cliente de um real desync do lado do servidor.
+A reutilização de conexão (keep-alive) e o pipelining podem facilmente produzir ilusões de "smuggling" em ferramentas de teste que enviam múltiplas requisições no mesmo socket. Aprenda a separar artefatos inofensivos do lado do cliente de um desync real do lado do servidor.

-### Why pipelining creates classic false positives
+### Por que o pipelining cria falsos positivos clássicos

-HTTP/1.1 reutiliza uma única conexão TCP/TLS e concatena requisições e respostas no mesmo stream. No pipelining, o cliente envia múltiplas requisições seguidas e espera respostas em ordem. Um falso positivo comum é reenviar um payload malformado no estilo CL.0 duas vezes em uma única conexão:
+HTTP/1.1 reutiliza uma única conexão TCP/TLS e concatena requisições e respostas no mesmo stream. No pipelining, o cliente envia múltiplas requisições em sequência e espera respostas na ordem. Um falso positivo comum é reenviar um payload malformado CL.0-style duas vezes em uma única conexão:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -343,7 +343,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Por favor cole aqui o conteúdo do arquivo src/pentesting-web/http-request-smuggling/README.md que você quer que eu traduza para português. Vou manter exatamente a mesma sintaxe Markdown/HTML e não traduzirei código, nomes de técnicas, palavras comuns de hacking, plataformas cloud, links, paths ou tags.
+Por favor cole o conteúdo do arquivo src/pentesting-web/http-request-smuggling/README.md que você quer traduzido. Vou manter exatamente a mesma sintaxe Markdown/HTML e não traduzirei código, nomes de técnicas, palavras comuns de hacking, links ou caminhos.
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -357,7 +357,7 @@ Content-Type: text/plain
 User-agent: *
 Disallow: /settings
 ```
-Se o servidor ignorou o `Content_Length` malformado, não há FE↔BE desync. Com reuso, seu cliente na verdade enviou este fluxo de bytes, que o servidor interpretou como duas requisições independentes:
+Se o servidor ignorou o `Content_Length` malformado, não há FE↔BE desync. Com reutilização, seu cliente na verdade enviou este fluxo de bytes, que o servidor interpretou como duas requisições independentes:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -371,79 +371,78 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Impacto: nenhum. Você apenas desincronizou seu cliente do framing do servidor.
+Impacto: nenhum. Você apenas dessincronizou seu cliente em relação ao enquadramento do servidor.

 > [!TIP]
-> Burp modules that depend on reuse/pipelining: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".
+> Módulos do Burp que dependem de reuse/pipelining: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".

-### Testes decisivos: pipelining ou desync real?
+### Testes decisivos: pipelining ou dessincronização real?

-1. Disable reuse and re-test
- In Burp Intruder/Repeater, turn off HTTP/1 reuse and avoid "Send group in sequence".
- In Turbo Intruder, set `requestsPerConnection=1` and `pipeline=False`.
- If the behavior disappears, it was likely client-side pipelining, unless you’re dealing with connection-locked/stateful targets or client-side desync.
-2. HTTP/2 nested-response check
- Send an HTTP/2 request. If the response body contains a complete nested HTTP/1 response, you’ve proven a backend parsing/desync bug instead of a pure client artifact.
-3. Partial-requests probe for connection-locked front-ends
- Some FEs only reuse the upstream BE connection if the client reused theirs. Use partial-requests to detect FE behavior that mirrors client reuse.
- See PortSwigger "Browser‑Powered Desync Attacks" for the connection-locked technique.
-4. State probes
- Look for first- vs subsequent-request differences on the same TCP connection (first-request routing/validation).
- Burp "HTTP Request Smuggler" includes a connection‑state probe that automates this.
-5. Visualize the wire
- Use the Burp "HTTP Hacker" extension to inspect concatenation and message framing directly while experimenting with reuse and partial requests.
+1. Desative a reutilização e teste novamente
+- No Burp Intruder/Repeater, desligue a reutilização HTTP/1 e evite "Send group in sequence".
+- No Turbo Intruder, defina `requestsPerConnection=1` e `pipeline=False`.
+- Se o comportamento desaparecer, provavelmente era pipelining do lado do cliente, a menos que você esteja lidando com alvos connection-locked/stateful ou dessincronização no lado do cliente.
+2. Verificação de nested-response em HTTP/2
+- Envie uma request HTTP/2. Se o corpo da resposta contiver uma resposta HTTP/1 completa aninhada, você provou um bug de parsing/dessincronização no backend em vez de um artefato puramente do cliente.
+3. Sonda de partial-requests para front-ends connection-locked
+- Alguns FEs só reutilizam a conexão upstream BE se o cliente reutilizou a sua. Use partial-requests para detectar comportamento do FE que espelha a reutilização do cliente.
+- Veja PortSwigger "Browser‑Powered Desync Attacks" para a técnica connection-locked.
+4. Sondas de estado
+- Procure diferenças entre a primeira request e as subsequentes na mesma conexão TCP (roteamento/validação da primeira request).
+- O Burp "HTTP Request Smuggler" inclui uma sonda de connection‑state que automatiza isso.
+5. Visualize o tráfego
+- Use a extensão Burp "HTTP Hacker" para inspecionar concatenação e framing de mensagens diretamente enquanto experimenta com reuse e partial requests.

 ### Connection‑locked request smuggling (reuse-required)

-Some front-ends only reuse the upstream connection when the client reuses theirs. Real smuggling exists but is conditional on client-side reuse. To distinguish and prove impact:
- Prove the server-side bug
- Use the HTTP/2 nested-response check, or
- Use partial-requests to show the FE only reuses upstream when the client does.
- Show real impact even if direct cross-user socket abuse is blocked:
+Alguns front-ends só reutilizam a conexão upstream quando o cliente reutiliza a sua. Smuggling real existe, mas é condicional à reutilização do lado do cliente. Para distinguir e provar impacto:
+- Prove o bug no lado do servidor
+- Use a verificação HTTP/2 nested-response, ou
+- Use partial-requests para mostrar que o FE só reutiliza upstream quando o cliente o faz.
+- Mostre impacto real mesmo se o abuso direto de socket entre usuários for bloqueado:
 - Cache poisoning: poison shared caches via the desync so responses affect other users.
 - Internal header disclosure: reflect FE-injected headers (e.g., auth/trust headers) and pivot to auth bypass.
 - Bypass FE controls: smuggle restricted paths/methods past the front-end.
 - Host-header abuse: combine with host routing quirks to pivot to internal vhosts.
- Operator workflow
- Reproduce with controlled reuse (Turbo Intruder `requestsPerConnection=2`, or Burp Repeater tab group → "Send group in sequence (single connection)").
- Then chain to cache/header-leak/control-bypass primitives and demonstrate cross-user or authorization impact.
+- Fluxo do operador
+- Reproduza com reutilização controlada (Turbo Intruder `requestsPerConnection=2`, ou Burp Repeater tab group → "Send group in sequence (single connection)").
+- Então encadeie para primitives de cache/header-leak/control-bypass e demonstre impacto entre usuários ou de autorização.

 > See also connection‑state attacks, which are closely related but not technically smuggling:
 >
 >{{#ref}}
 >../http-connection-request-smuggling.md
->
-{{#endref}}
+>{{#endref}}

-### Client‑side desync constraints
+### Restrições de dessincronização do lado do cliente

-If you’re targeting browser-powered/client-side desync, the malicious request must be sendable by a browser cross-origin. Header obfuscation tricks won’t work. Focus on primitives reachable via navigation/fetch, and then pivot to cache poisoning, header disclosure, or front-end control bypass where downstream components reflect or cache responses.
+Se você estiver mirando em browser-powered/client-side desync, a request maliciosa precisa ser enviável por um navegador cross-origin. Truques de obfuscação de headers não funcionarão. Foque em primitives acessíveis via navegação/fetch, e então pivote para cache poisoning, header disclosure, ou front-end control bypass quando componentes downstream refletirem ou cachearem respostas.

-For background and end-to-end workflows:
+Para background e fluxos de trabalho end-to-end:

 {{#ref}}
 browser-http-request-smuggling.md
 {{#endref}}

-### Tooling to help decide
+### Ferramentas para ajudar a decidir

- HTTP Hacker (Burp BApp Store): exposes low-level HTTP behavior and socket concatenation.
+- HTTP Hacker (Burp BApp Store): expõe comportamento HTTP de baixo nível e concatenação de sockets.
 - "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
- Turbo Intruder: precise control over connection reuse via `requestsPerConnection`.
- Burp HTTP Request Smuggler: includes a connection‑state probe to spot first‑request routing/validation.
+- Turbo Intruder: controle preciso sobre connection reuse via `requestsPerConnection`.
+- Burp HTTP Request Smuggler: inclui uma sonda de connection‑state para detectar roteamento/validação da primeira request.

 > [!NOTE]
-> Treat reuse-only effects as non-issues unless you can prove server-side desync and attach concrete impact (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).
+> Trate efeitos que dependem apenas de reuse como não-problemas, a menos que você consiga provar dessincronização no lado do servidor e anexar impacto concreto (artefato de cache envenenado, header interno vazado que permite bypass de privilégios, controle do FE contornado, etc.).

 ## Abusing HTTP Request Smuggling

-### Circumventing Front-End Security via HTTP Request Smuggling
+### Circunvencendo a segurança do Front-End via HTTP Request Smuggling

-Sometimes, front-end proxies enforce security measures, scrutinizing incoming requests. However, these measures can be circumvented by exploiting HTTP Request Smuggling, allowing unauthorized access to restricted endpoints. For instance, accessing `/admin` might be prohibited externally, with the front-end proxy actively blocking such attempts. Nonetheless, this proxy may neglect to inspect embedded requests within a smuggled HTTP request, leaving a loophole for bypassing these restrictions.
+Às vezes, proxies front-end aplicam medidas de segurança, inspecionando requests recebidas. No entanto, essas medidas podem ser contornadas explorando HTTP Request Smuggling, permitindo acesso não autorizado a endpoints restritos. Por exemplo, acessar `/admin` pode ser proibido externamente, com o proxy front-end bloqueando ativamente tais tentativas. Ainda assim, esse proxy pode deixar de inspeccionar requests embutidas dentro de uma request smuggled, deixando uma brecha para contornar essas restrições.

-Consider the following examples illustrating how HTTP Request Smuggling can be used to bypass front-end security controls, specifically targeting the `/admin` path which is typically guarded by the front-end proxy:
+Considere os exemplos a seguir ilustrando como HTTP Request Smuggling pode ser usado para contornar controles de segurança do front-end, especificamente direcionando o caminho `/admin` que normalmente é protegido pelo proxy do front-end:

-**CL.TE Exemplo**
+**CL.TE Example**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@ -460,9 +459,9 @@ Content-Length: 10

 x=
 ```
-No ataque CL.TE, o cabeçalho `Content-Length` é aproveitado para a requisição inicial, enquanto a requisição embutida subsequente utiliza o cabeçalho `Transfer-Encoding: chunked`. O proxy front-end processa a requisição `POST` inicial, mas não inspeciona a requisição embutida `GET /admin`, permitindo acesso não autorizado ao caminho `/admin`.
+No ataque CL.TE, o cabeçalho `Content-Length` é utilizado para a requisição inicial, enquanto a requisição incorporada subsequente utiliza o cabeçalho `Transfer-Encoding: chunked`. O proxy front-end processa a requisição `POST` inicial mas falha ao inspecionar a requisição incorporada `GET /admin`, permitindo acesso não autorizado ao caminho `/admin`.

-**TE.CL Example**
+**Exemplo de TE.CL**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@ -478,13 +477,13 @@ a=x
 0

 ```
-Por outro lado, no ataque TE.CL, o `POST` inicial usa `Transfer-Encoding: chunked`, e a request embutida subsequente é processada com base no cabeçalho `Content-Length`. Semelhante ao ataque CL.TE, o proxy front-end ignora a requisição smuggled `GET /admin`, concedendo inadvertidamente acesso ao caminho restrito `/admin`.
+Por outro lado, no ataque TE.CL, a requisição inicial `POST` usa `Transfer-Encoding: chunked`, e a requisição embutida subsequente é processada com base no cabeçalho `Content-Length`. Similar ao ataque CL.TE, o proxy front-end ignora a requisição `GET /admin` escondida, concedendo inadvertidamente acesso ao caminho restrito `/admin`.

-### Revelando reescrita de requests do front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
+### Revelando reescrita de requisições no front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>

-As aplicações frequentemente empregam um **front-end server** para modificar incoming requests antes de repassá-las ao **back-end server**. Uma modificação típica envolve adicionar headers, tais como `X-Forwarded-For: <IP of the client>`, para transmitir o IP do cliente ao back-end. Entender essas modificações pode ser crucial, pois pode revelar formas de **bypass protections** ou **descobrir informações ou endpoints ocultos**.
+Aplicações frequentemente empregam um **servidor front-end** para modificar requisições recebidas antes de repassá-las ao servidor back-end. Uma modificação típica envolve adicionar headers, como `X-Forwarded-For: <IP of the client>`, para repassar o IP do cliente ao back-end. Entender essas modificações pode ser crucial, pois pode revelar maneiras de **contornar proteções** ou **descobrir informação ou endpoints ocultos**.

-Para investigar como um proxy altera uma request, localize um parâmetro POST que o back-end ecoa na resposta. Em seguida, construa uma request, usando esse parâmetro por último, semelhante ao seguinte:
+Para investigar como um proxy altera uma requisição, localize um parâmetro POST que o back-end ecoa na resposta. Então, construa uma requisição, usando esse parâmetro por último, semelhante ao seguinte:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -501,19 +500,19 @@ Content-Length: 100

 search=
 ```
-Nesta estrutura, componentes subsequentes do request são anexados após `search=`, que é o parâmetro refletido na resposta. Essa reflexão irá expor os headers do request subsequente.
+Nessa estrutura, componentes de requisição subsequentes são anexados após `search=`, que é o parâmetro refletido na resposta. Essa reflexão exporá os cabeçalhos da requisição subsequente.

-É importante alinhar o header `Content-Length` do request aninhado com o comprimento real do conteúdo. Começar com um valor pequeno e aumentá-lo gradualmente é aconselhável, pois um valor muito baixo truncará os dados refletidos, enquanto um valor muito alto pode fazer com que o request gere erro.
+É importante alinhar o cabeçalho `Content-Length` da requisição aninhada com o tamanho real do conteúdo. É recomendável começar com um valor pequeno e aumentá-lo gradualmente: um valor muito baixo truncará os dados refletidos, enquanto um valor muito alto pode fazer com que a requisição gere erro.

-Essa técnica também é aplicável no contexto de uma vulnerabilidade TE.CL, mas o request deve terminar com `search=\r\n0`. Independentemente dos caracteres de nova linha, os valores serão anexados ao parâmetro `search`.
+Essa técnica também se aplica no contexto de uma vulnerabilidade TE.CL, mas a requisição deve terminar com `search=\r\n0`. Independentemente dos caracteres de nova linha, os valores serão anexados ao parâmetro search.

-Esse método serve principalmente para entender as modificações do request feitas pelo proxy de front-end, essencialmente realizando uma investigação autodirigida.
+Esse método serve principalmente para entender as modificações nas requisições feitas pelo front-end proxy, funcionando essencialmente como uma investigação autodirigida.

-### Capturando as requests de outros usuários <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
+### Capturando as requisições de outros usuários <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

-É possível capturar as requests do próximo usuário anexando uma request específica como valor de um parâmetro durante uma operação POST. Veja como isso pode ser feito:
+É possível capturar as requisições do próximo usuário anexando uma requisição específica como valor de um parâmetro durante uma operação POST. Veja como isso pode ser feito:

-Anexando a seguinte request como valor de um parâmetro, você pode armazenar a request do cliente subsequente:
+Anexando a seguinte requisição como valor de um parâmetro, você pode armazenar a requisição do cliente subsequente:
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@ -533,20 +532,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-Neste cenário, o **parâmetro comment** destina-se a armazenar o conteúdo da seção de comentários de um post em uma página publicamente acessível. Consequentemente, o conteúdo da requisição subsequente aparecerá como um comentário.
+Neste cenário, o **parâmetro comment** destina-se a armazenar o conteúdo da seção de comentários de um post em uma página de acesso público. Consequentemente, o conteúdo da requisição subsequente aparecerá como um comentário.

-No entanto, esta técnica tem limitações. Geralmente, ela captura dados apenas até o delimitador de parâmetro usado na requisição smuggled. Para envios de formulário URL-encoded, esse delimitador é o caractere `&`. Isso significa que o conteúdo capturado da requisição do usuário vítima vai parar no primeiro `&`, que pode até fazer parte da query string.
+No entanto, essa técnica tem limitações. Geralmente, ela captura dados apenas até o delimitador de parâmetro usado na requisição smuggled. Para envios de formulário URL-encoded, esse delimitador é o caractere `&`. Isso significa que o conteúdo capturado da requisição do usuário vítima vai parar no primeiro `&`, que pode até fazer parte da query string.

-Além disso, vale notar que esta abordagem também é viável com uma vulnerabilidade TE.CL. Nesses casos, a requisição deve terminar com `search=\r\n0`. Independentemente dos caracteres de nova linha, os valores serão anexados ao parâmetro search.
+Além disso, vale notar que essa abordagem também é viável com uma vulnerabilidade TE.CL. Nesses casos, a requisição deve terminar com `search=\r\n0`. Independentemente dos caracteres de nova linha, os valores serão anexados ao parâmetro search.

 ### Usando HTTP request smuggling para explorar Reflected XSS

 HTTP Request Smuggling pode ser aproveitado para explorar páginas web vulneráveis a **Reflected XSS**, oferecendo vantagens significativas:

- A interação com os usuários alvo **não é necessária**.
- Permite a exploração de XSS em partes da requisição que são **normalmente inalcançáveis**, como os headers da requisição HTTP.
+- A interação com os usuários-alvo **não é necessária**.
+- Permite a exploração de XSS em partes da requisição que são **normalmente inacessíveis**, como os cabeçalhos HTTP.

-Em cenários onde um site é suscetível a Reflected XSS através do header User-Agent, o seguinte payload demonstra como explorar essa vulnerabilidade:
+Em cenários onde um site é suscetível a Reflected XSS via o cabeçalho User-Agent, o payload a seguir demonstra como explorar essa vulnerabilidade:
 ```
 POST / HTTP/1.1
 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@ -569,24 +568,24 @@ A=
 ```
 Este payload é estruturado para explorar a vulnerabilidade da seguinte forma:

-1. Iniciando uma requisição `POST`, aparentemente típica, com o cabeçalho `Transfer-Encoding: chunked` para indicar o início do smuggling.
-2. Em seguida com um `0`, marcando o fim do corpo da mensagem chunked.
-3. Então, uma requisição `GET` smuggled é inserida, onde o cabeçalho `User-Agent` é injetado com um script, `<script>alert(1)</script>`, disparando o XSS quando o servidor processa essa requisição subsequente.
+1. Iniciando uma requisição `POST`, aparentemente típica, com um cabeçalho `Transfer-Encoding: chunked` para indicar o início do smuggling.
+2. Seguindo com um `0`, marcando o fim do corpo da mensagem chunked.
+3. Em seguida, é introduzida uma requisição `GET` smuggled, onde o cabeçalho `User-Agent` é injetado com um script, `<script>alert(1)</script>`, disparando o XSS quando o servidor processa essa requisição subsequente.

-Ao manipular o `User-Agent` via smuggling, o payload contorna as restrições normais de requisição, explorando assim a vulnerabilidade Reflected XSS de maneira não convencional, mas eficaz.
+Ao manipular o `User-Agent` através do smuggling, o payload contorna as restrições normais de requisição, explorando assim a vulnerabilidade Reflected XSS de forma não-padrão, mas eficaz.

 #### HTTP/0.9

 > [!CAUTION]
-> Caso o conteúdo do usuário seja refletido em uma resposta com um **`Content-type`** como **`text/plain`**, impedindo a execução do XSS. Se o servidor suportar **HTTP/0.9 pode ser possível contornar isso**!
+> Caso o conteúdo do usuário seja refletido em uma resposta com um **`Content-type`** como **`text/plain`**, isso impede a execução do XSS. Se o servidor suportar **HTTP/0.9** pode ser possível contornar isso!

-A versão HTTP/0.9 precedeu a 1.0 e usa apenas o verbo **GET** e **não** responde com **headers**, apenas com o corpo.
+A versão HTTP/0.9 precedeu a 1.0 e usa apenas verbos **GET** e **não** responde com **headers**, apenas o body.

-Em [**this writeup**](https://mizu.re/post/twisty-python), isso foi abusado com um request smuggling e um vulnerable endpoint que responde com a entrada do usuário para smugglear uma requisição com HTTP/0.9. O parâmetro que seria refletido na resposta continha uma fake HTTP/1.1 response (with headers and body) então a resposta passou a conter código JS executável válido com um `Content-Type` de `text/html`.
+In [**this writeup**](https://mizu.re/post/twisty-python), isso foi abusado com um request smuggling e um endpoint vulnerável que responde com a entrada do usuário para smuggle uma requisição com HTTP/0.9. O parâmetro que seria refletido na resposta continha uma **resposta HTTP/1.1 falsa (com headers e body)**, então a resposta passou a conter código JS executável válido com um `Content-Type` de `text/html`.

-### Explorando redirecionamentos on-site com HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
+### Explorando On-site Redirects com HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>

-Aplicações frequentemente redirecionam de uma URL para outra usando o hostname do cabeçalho `Host` na URL de redirect. Isso é comum em web servers como Apache e IIS. Por exemplo, requisitar uma pasta sem a barra final resulta em um redirect para incluir a barra:
+Aplicações frequentemente redirecionam de uma URL para outra usando o nome do host do cabeçalho `Host` na URL de redirecionamento. Isso é comum em web servers como Apache e IIS. Por exemplo, solicitar uma pasta sem uma barra final resulta em um redirecionamento para incluir a barra:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
@ -610,7 +609,7 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-Esta requisição smuggled poderia fazer com que a próxima requisição de usuário processada fosse redirecionada para um site controlado por um atacante:
+Esta smuggled request poderia fazer com que a próxima solicitação de usuário processada seja redirecionada para um site controlado pelo atacante:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
@ -622,17 +621,17 @@ Resulta em:
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-In this scenario, a user's request for a JavaScript file is hijacked. The attacker can potentially compromise the user by serving malicious JavaScript in response.
+Neste cenário, a requisição de um usuário por um arquivo JavaScript é sequestrada. O atacante pode potencialmente comprometer o usuário servindo JavaScript malicioso em resposta.

-### Exploiting Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### Explorando Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-Web cache poisoning pode ser executado se qualquer componente da **front-end infrastructure caches content**, tipicamente para melhorar o desempenho. Manipulando a resposta do servidor, é possível **poison the cache**.
+Web cache poisoning pode ser executado se qualquer componente da **infraestrutura front-end armazenar conteúdo**, tipicamente para melhorar a performance. Ao manipular a resposta do servidor, é possível **poison the cache**.

-Anteriormente, observamos como as respostas do servidor podiam ser alteradas para retornar um erro 404 (consulte [Basic Examples](#basic-examples)). Da mesma forma, é viável enganar o servidor para que entregue o conteúdo de `/index.html` em resposta a uma requisição por `/static/include.js`. Consequentemente, o conteúdo de `/static/include.js` é substituído na cache pelo de `/index.html`, tornando `/static/include.js` inacessível aos usuários, potencialmente levando a um Denial of Service (DoS).
+Anteriormente, observamos como as respostas do servidor podiam ser alteradas para retornar um erro 404 (consulte [Basic Examples](#basic-examples)). De forma semelhante, é factível enganar o servidor para entregar o conteúdo de `/index.html` em resposta a uma requisição por `/static/include.js`. Consequentemente, o conteúdo de `/static/include.js` é substituído no cache pelo de `/index.html`, tornando `/static/include.js` inacessível aos usuários e potencialmente levando a um Denial of Service (DoS).

-Essa técnica se torna particularmente potente se for descoberta uma **Open Redirect vulnerability** ou se houver um **on-site redirect to an open redirect**. Tais vulnerabilidades podem ser exploradas para substituir o conteúdo em cache de `/static/include.js` por um script sob controle do atacante, essencialmente possibilitando um ataque generalizado de Cross-Site Scripting (XSS) contra todos os clientes que requisitarem o `/static/include.js` atualizado.
+Essa técnica torna-se particularmente potente se uma **Open Redirect vulnerability** for descoberta ou se houver um **on-site redirect to an open redirect**. Tais vulnerabilidades podem ser exploradas para substituir o conteúdo em cache de `/static/include.js` por um script controlado pelo atacante, essencialmente permitindo um ataque Cross-Site Scripting (XSS) em larga escala contra todos os clientes que requisitarem o `/static/include.js` atualizado.

-Abaixo está uma ilustração de exploração de **cache poisoning combined with an on-site redirect to open redirect**. O objetivo é alterar o conteúdo em cache de `/static/include.js` para servir código JavaScript controlado pelo atacante:
+Abaixo há uma ilustração de explorar **cache poisoning combined with an on-site redirect to open redirect**. O objetivo é alterar o conteúdo do cache de `/static/include.js` para servir código JavaScript controlado pelo atacante:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@ -650,20 +649,20 @@ Content-Length: 10

 x=1
 ```
-Observe a request embutida que tem como alvo `/post/next?postId=3`. Essa request será redirecionada para `/post?postId=4`, utilizando o **Host header value** para determinar o domínio. Ao alterar o **Host header**, o atacante pode redirecionar a request para o seu domínio (**on-site redirect to open redirect**).
+Note the embedded request targeting `/post/next?postId=3`. This request will be redirected to `/post?postId=4`, utilizing the **Host header value** to determine the domain. By altering the **Host header**, the attacker can redirect the request to their domain (**on-site redirect to open redirect**).

-Após um **socket poisoning** bem-sucedido, uma **GET request** para `/static/include.js` deve ser iniciada. Essa request será contaminada pela anterior **on-site redirect to open redirect** request e buscará o conteúdo do script controlado pelo atacante.
+Após um **socket poisoning** bem-sucedido, deve ser iniciada uma **GET request** para `/static/include.js`. Essa request será contaminada pela request anterior (**on-site redirect to open redirect**) e buscará o conteúdo do script controlado pelo atacante.

-Posteriormente, qualquer request para `/static/include.js` servirá o conteúdo em cache do script do atacante, lançando efetivamente um XSS attack em larga escala.
+Em seguida, qualquer request para `/static/include.js` servirá o conteúdo em cache do script do atacante, efetivamente lançando um amplo **XSS attack**.

 ### Using HTTP request smuggling to perform web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>

 > **Qual é a diferença entre web cache poisoning e web cache deception?**
 >
-> - Em **web cache poisoning**, o atacante faz com que a aplicação armazene conteúdo malicioso no cache, e esse conteúdo é servido a partir do cache para outros usuários da aplicação.
-> - Em **web cache deception**, o atacante faz com que a aplicação armazene conteúdo sensível pertencente a outro usuário no cache, e então o atacante recupera esse conteúdo do cache.
-
-O atacante constrói uma smuggled request que obtém conteúdo sensível específico do usuário. Considere o seguinte exemplo:
+> - Em **web cache poisoning**, o atacante faz com que a aplicação armazene algum conteúdo malicioso no cache, e esse conteúdo é servido a outros usuários da aplicação a partir do cache.
+> - Em **web cache deception**, o atacante faz com que a aplicação armazene conteúdo sensível pertencente a outro usuário no cache, e em seguida o atacante recupera esse conteúdo do cache.
+>
+> O atacante cria um smuggled request que busca conteúdo sensível específico de um usuário. Considere o seguinte exemplo:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@ -674,17 +673,17 @@ O atacante constrói uma smuggled request que obtém conteúdo sensível especí
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-Se essa requisição, enviada por HTTP Request Smuggling, envenenar uma entrada de cache destinada a conteúdo estático (por exemplo, `/someimage.png`), os dados sensíveis da vítima de `/private/messages` podem ser armazenados nessa entrada de cache do conteúdo estático. Consequentemente, o atacante poderia potencialmente recuperar esses dados sensíveis em cache.
+Se essa smuggled request contaminar uma entrada de cache destinada a conteúdo estático (por exemplo, `/someimage.png`), os dados sensíveis da vítima de `/private/messages` podem ser armazenados sob a entrada de cache do conteúdo estático. Consequentemente, o atacante poderia potencialmente recuperar esses dados sensíveis em cache.

 ### Abusando do TRACE via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-[**In this post**](https://portswigger.net/research/trace-desync-attack) sugere que, se o servidor tiver o método TRACE habilitado, pode ser possível abusar dele com um HTTP Request Smuggling. Isso ocorre porque esse método reflete qualquer header enviado ao servidor como parte do corpo da resposta. Por exemplo:
+[**In this post**](https://portswigger.net/research/trace-desync-attack) é sugerido que, se o servidor tiver o método TRACE habilitado, pode ser possível abusar dele com um HTTP Request Smuggling. Isso porque esse método refletirá qualquer header enviado ao servidor como parte do corpo da resposta. Por exemplo:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Por favor cole aqui o conteúdo de src/pentesting-web/http-request-smuggling/README.md que deseja traduzir. Vou traduzir o texto relevante para português mantendo exatamente a mesma sintaxe markdown/html e sem traduzir código, nomes de técnicas, links ou tags.
+Por favor, cole o conteúdo do arquivo src/pentesting-web/http-request-smuggling/README.md que deseja que eu traduza para português. Vou manter exatamente a mesma sintaxe Markdown/HTML e não traduzirei código, nomes de técnicas, links, paths ou tags.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@ -695,15 +694,15 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-Um exemplo de como abusar desse comportamento seria smuggle primeiro um HEAD request. Esse request será respondido apenas com os headers de um GET request (**`Content-Type`** entre eles). E smuggle imediatamente após o HEAD um TRACE request, que irá **refletir os dados enviados**.\
-Como o HEAD response conterá um `Content-Length` header, a **response do TRACE request será tratada como o body do HEAD response, portanto refletindo dados arbitrários** na response.\
-Essa response será enviada para a próxima request na conexão, então isso poderia ser **usado em um arquivo JS em cache, por exemplo, para injetar código JS arbitrário**.
+Um exemplo de como abusar desse comportamento seria **smuggle first a HEAD request**. Esse pedido será respondido apenas com os **headers** de um GET request (**`Content-Type`** entre eles). E smuggle **immediately after the HEAD a TRACE request**, que será **reflecting the sent dat**a.\
+Como a resposta ao HEAD conterá um cabeçalho `Content-Length`, a **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** na resposta.\
+Essa resposta será enviada para a próxima request pela conexão, então isso poderia ser **used in a cached JS file for example to inject arbitrary JS code**.

 ### Abusing TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-Continuar seguindo [**this post**](https://portswigger.net/research/trace-desync-attack) é sugerida outra forma de abusar do método TRACE. Como comentado, ao smuggle um HEAD request e um TRACE request é possível **controlar alguns dados refletidos** na response ao HEAD request. O comprimento do body do HEAD request é basicamente indicado no `Content-Length` header e é formado pela response do TRACE request.
+Seguir [**this post**](https://portswigger.net/research/trace-desync-attack) é sugerido como outra forma de abusar do método TRACE. Como comentado, ao smuggle um HEAD request e um TRACE request é possível **control some reflected data** na resposta ao HEAD request. O comprimento do corpo do HEAD request é basicamente indicado no cabeçalho Content-Length e é formado pela resposta ao TRACE request.

-Portanto, a nova ideia seria que, conhecendo esse `Content-Length` e os dados fornecidos na response do TRACE, é possível fazer com que a response do TRACE contenha uma resposta HTTP válida depois do último byte indicado pelo Content-Length, permitindo a um atacante controlar completamente a request para a próxima response (o que poderia ser usado para realizar um cache poisoning).
+Portanto, a nova ideia seria que, conhecendo esse Content-Length e os dados fornecidos na TRACE response, é possível fazer com que a TRACE response contenha uma HTTP response válida após o último byte do Content-Length, permitindo que um atacante controle completamente a request para a próxima resposta (o que poderia ser usado para realizar um cache poisoning).

 Example:
 ```
@ -724,7 +723,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-Gerará estas respostas (note que a resposta HEAD tem um Content-Length, fazendo com que a resposta TRACE seja parte do corpo da HEAD e, uma vez que o Content-Length da HEAD termina, uma resposta HTTP válida é smuggled):
+Isso gerará estas respostas (observe como a resposta HEAD tem um Content-Length, fazendo com que a resposta TRACE seja parte do corpo da HEAD e, uma vez que o Content-Length da HEAD termina, uma resposta HTTP válida é smuggled):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -745,10 +744,9 @@ Content-Length: 50

 <script>alert(“arbitrary response”)</script>
 ```
-### Explorando HTTP Request Smuggling com HTTP Response Desynchronisation
-
-Encontrou alguma vulnerabilidade de HTTP Request Smuggling e não sabe como explorá-la? Experimente este outro método de exploração:
+### Potencializando HTTP Request Smuggling com HTTP Response Desynchronisation

+Você encontrou alguma vulnerabilidade de HTTP Request Smuggling e não sabe como explorá-la? Experimente estes outros métodos de exploração:

 {{#ref}}
 ../http-response-smuggling-desync.md
@ -770,11 +768,11 @@ browser-http-request-smuggling.md
 request-smuggling-in-http-2-downgrades.md
 {{#endref}}

-## Scripts do Turbo Intruder
+## Turbo intruder scripts

 ### CL.TE

-Fonte: [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
+From [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
 ```python
 def queueRequests(target, wordlists):

@ -815,7 +813,7 @@ table.add(req)
 ```
 ### TE.CL

-Fonte: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)
+De: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)
 ```python
 def queueRequests(target, wordlists):
 engine = RequestEngine(endpoint=target.endpoint,
@ -866,7 +864,7 @@ table.add(req)
 - [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 ferramenta é um HTTP Fuzzer baseado em gramática, útil para encontrar discrepâncias estranhas de request smuggling.
+- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Esta ferramenta é um HTTP Fuzzer baseado em gramática útil para encontrar discrepâncias estranhas de request smuggling.

 ## Referências