Translated ['src/pentesting-web/http-request-smuggling/README.md', 'src/

src/pentesting-web/http-request-smuggling/README.md

@@ -19,7 +19,7 @@ Isso permite que um usuário **modifique a próxima requisição que chega ao se
 
 **Transfer-Encoding: chunked**
 
-> O cabeçalho Transfer-Encoding especifica a forma de codificação usada para transferir com segurança o corpo da carga útil para o usuário.\
+> O cabeçalho Transfer-Encoding especifica a forma de codificação usada para transferir com segurança o corpo do payload para o usuário.\
 > Chunked significa que grandes dados são enviados em uma série de pedaços.
 
 ### Realidade
@@ -32,7 +32,7 @@ Isso pode ser muito crítico, pois **um atacante poderá enviar uma requisição
 Lembre-se de que em HTTP **um caractere de nova linha é composto por 2 bytes:**
 
 - **Content-Length**: Este cabeçalho usa um **número decimal** para indicar o **número** de **bytes** do **corpo** da requisição. O corpo deve terminar no último caractere, **uma nova linha não é necessária no final da requisição**.
-- **Transfer-Encoding:** Este cabeçalho usa no **corpo** um **número hexadecimal** para indicar o **número** de **bytes** do **próximo pedaço**. O **pedaço** deve **terminar** com uma **nova linha**, mas essa nova linha **não é contada** pelo indicador de comprimento. Este método de transferência deve terminar com um **pedaço de tamanho 0 seguido por 2 novas linhas**: `0`
+- **Transfer-Encoding:** Este cabeçalho usa no **corpo** um **número hexadecimal** para indicar o **número** de **bytes** do **próximo pedaço**. O **pedaço** deve **terminar** com uma **nova linha**, mas essa nova linha **não é contada** pelo indicador de comprimento. Este método de transferência deve terminar com um **pedaço de tamanho 0 seguido de 2 novas linhas**: `0`
 - **Connection**: Com base na minha experiência, é recomendável usar **`Connection: keep-alive`** na primeira requisição do HTTP Request Smuggling.
 
 ## Exemplos Básicos
@@ -40,14 +40,14 @@ Lembre-se de que em HTTP **um caractere de nova linha é composto por 2 bytes:**
 > [!TIP]
 > Ao tentar explorar isso com Burp Suite **desative `Update Content-Length` e `Normalize HTTP/1 line endings`** no repetidor, pois alguns gadgets abusam de novas linhas, retornos de carro e content-lengths malformados.
 
-Os ataques de HTTP request smuggling são elaborados enviando requisições ambíguas que exploram discrepâncias em como os servidores de 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 de front-end e back-end priorizam esses cabeçalhos. As vulnerabilidades surgem do processamento da mesma requisição de maneiras diferentes pelos servidores, levando a resultados inesperados e potencialmente maliciosos.
+Os ataques de HTTP request smuggling são elaborados enviando requisições ambíguas que exploram discrepâncias em como os servidores de 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 de front-end e back-end priorizam esses cabeçalhos. As vulnerabilidades surgem do processamento da mesma requisição pelos servidores 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)
 
-> [!NOTE]
-> À tabela anterior, você deve adicionar a técnica TE.0, como a técnica CL.0, mas usando Transfer Encoding.
+> [!TIP]
+> Na tabela anterior, você deve adicionar a técnica TE.0, como a técnica CL.0, mas usando Transfer Encoding.
 
 #### Vulnerabilidade CL.TE (Content-Length usado pelo Front-End, Transfer-Encoding usado pelo Back-End)
 
@@ -183,9 +183,9 @@ EMPTY_LINE_HERE
 ```
 #### Quebrando o servidor web
 
-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**. Dessa forma, o **corpo** da requisição HTTP será considerado a **próxima requisição HTTP**.
+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**. Dessa forma, o **corpo** da solicitação HTTP será considerado a **próxima solicitação HTTP**.
 
-Por exemplo, como explicado em [**este artigo**](https://mizu.re/post/twisty-python), no Werkzeug era possível enviar alguns **caracteres Unicode** e isso faria o servidor **quebrar**. No entanto, se a conexão HTTP foi criada com o cabeçalho **`Connection: keep-alive`**, o corpo da requisição não será lido e a conexão ainda estará aberta, então o **corpo** da requisição será tratado como a **próxima requisição HTTP**.
+Por exemplo, como explicado em [**este artigo**](https://mizu.re/post/twisty-python), no Werkzeug era possível enviar alguns **caracteres Unicode** e isso faria o servidor **quebrar**. No entanto, se a conexão HTTP foi criada com o cabeçalho **`Connection: keep-alive`**, o corpo da solicitação não será lido e a conexão ainda estará aberta, então o **corpo** da solicitação será tratado como a **próxima solicitação HTTP**.
 
 #### Forçando via cabeçalhos hop-by-hop
 
@@ -259,7 +259,7 @@ X
 - **Usando Ferramentas Automatizadas:**
 - Ferramentas como a extensão 'HTTP Request Smuggler' do Burp Suite podem testar automaticamente essas vulnerabilidades enviando várias formas de solicitações ambíguas e analisando as respostas.
 - **Testes de Variação de Content-Length:**
-- Envie solicitações com valores de `Content-Length` variados que não estão alinhados com o comprimento real do conteúdo e observe como o servidor lida com tais incompatibilidades.
+- Envie solicitações com valores de `Content-Length` variados que não estão alinhados com o comprimento real do conteúdo e observe como o servidor lida com tais discrepâncias.
 - **Testes de Variação de Transfer-Encoding:**
 - Envie solicitações com cabeçalhos `Transfer-Encoding` ofuscados ou malformados e monitore como os servidores front-end e back-end respondem de maneira diferente a tais manipulações.
 
@@ -272,18 +272,124 @@ Após confirmar a eficácia das técnicas de temporização, é crucial verifica
 Ao testar vulnerabilidades de request smuggling interferindo em outras solicitações, tenha em mente:
 
 - **Conexões de Rede Distintas:** As solicitações "ataque" e "normais" 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 e nomes de parâmetros idênticos para ambas as solicitações. Aplicações modernas frequentemente roteiam solicitações para servidores back-end específicos com base em URL e parâmetros. Correspondendo a esses aumenta a probabilidade de que ambas as solicitações sejam processadas pelo mesmo servidor, um pré-requisito para um ataque bem-sucedido.
-- **Condições de Temporização e Corrida:** A solicitação "normal", destinada a detectar interferência da solicitação "ataque", compete contra outras solicitações de aplicação concorrentes. Portanto, envie a solicitação "normal" imediatamente após a solicitação "ataque". Aplicações ocupadas podem exigir várias tentativas para confirmação conclusiva da vulnerabilidade.
+- **URL e Parâmetros Consistentes:** Tente usar URLs e nomes de parâmetros idênticos para ambas as solicitações. Aplicações modernas frequentemente roteiam solicitações para servidores back-end específicos com base em URL e parâmetros. Correspondendo a esses aumenta a probabilidade de que ambas as solicitações sejam processadas pelo mesmo servidor, um pré-requisito para um ataque bem-sucedido.
+- **Condições de Temporização e Corrida:** A solicitação "normal", destinada a detectar interferência da solicitação "ataque", compete contra outras solicitações concorrentes da aplicação. Portanto, envie a solicitação "normal" imediatamente após a solicitação "ataque". Aplicações ocupadas podem exigir várias tentativas para confirmação conclusiva da vulnerabilidade.
 - **Desafios de Balanceamento de Carga:** Servidores front-end atuando como balanceadores de carga podem distribuir solicitações entre vários sistemas back-end. Se as solicitações "ataque" e "normais" acabarem em sistemas diferentes, o ataque não terá sucesso. Esse aspecto de balanceamento de carga pode exigir várias tentativas para confirmar uma vulnerabilidade.
 - **Impacto Não Intencional ao Usuário:** Se seu ataque impactar inadvertidamente a solicitação de outro usuário (não a solicitaçã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.
 
-## Abusando de HTTP Request Smuggling
+## Distinguindo artefatos de pipelining HTTP/1.1 vs verdadeiro request smuggling
+
+A reutilização de conexão (keep-alive) e o pipelining podem facilmente produzir ilusões de "smuggling" em ferramentas de teste que enviam várias solicitações no mesmo socket. Aprenda a separar artefatos inofensivos do lado do cliente de verdadeiros desincronizações do lado do servidor.
+
+### Por que o pipelining cria falsos positivos clássicos
+
+HTTP/1.1 reutiliza uma única conexão TCP/TLS e concatena solicitações e respostas no mesmo fluxo. No pipelining, o cliente envia várias solicitações uma após a outra e depende de respostas em ordem. Um falso positivo comum é reenviar uma carga malformada no estilo CL.0 duas vezes em uma única conexão:
+```
+POST / HTTP/1.1
+Host: hackxor.net
+Content_Length: 47
+
+GET /robots.txt HTTP/1.1
+X: Y
+```
+As respostas podem parecer:
+```
+HTTP/1.1 200 OK
+Content-Type: text/html
+
+```
+
+```
+HTTP/1.1 200 OK
+Content-Type: text/plain
+
+User-agent: *
+Disallow: /settings
+```
+Se o servidor ignorou o `Content_Length` malformado, não há desincronização FE↔BE. Com reutilização, seu cliente realmente enviou este fluxo de bytes, que o servidor analisou como duas solicitações independentes:
+```
+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: nenhum. Você apenas desincronizou seu cliente do enquadramento do servidor.
+
+> [!TIP]
+> Módulos do Burp que dependem de reutilização/pipelining: Turbo Intruder com `requestsPerConnection>1`, Intruder com "reutilização de conexão HTTP/1", Repeater "Enviar grupo em sequência (conexão única)" ou "Habilitar reutilização de conexão".
+
+### Testes de litmus: pipelining ou desincronização real?
+
+1. Desative a reutilização e reteste
+- No Burp Intruder/Repeater, desative a reutilização HTTP/1 e evite "Enviar grupo em sequência".
+- No Turbo Intruder, defina `requestsPerConnection=1` e `pipeline=False`.
+- Se o comportamento desaparecer, provavelmente foi pipelining do lado do cliente, a menos que você esteja lidando com alvos bloqueados por conexão/estaduais ou desincronização do lado do cliente.
+2. Verificação de resposta aninhada HTTP/2
+- Envie uma solicitação HTTP/2. Se o corpo da resposta contiver uma resposta HTTP/1 aninhada completa, você provou um bug de análise/desincronização no backend em vez de um artefato puro do cliente.
+3. Sonda de solicitações parciais para front-ends bloqueados por conexão
+- Alguns FEs só reutilizam a conexão BE upstream se o cliente reutilizar a sua. Use solicitações parciais para detectar o comportamento do FE que espelha a reutilização do cliente.
+- Veja PortSwigger "Browser‑Powered Desync Attacks" para a técnica bloqueada por conexão.
+4. Sondas de estado
+- Procure diferenças entre a primeira e as solicitações subsequentes na mesma conexão TCP (roteamento/validação da primeira solicitação).
+- O Burp "HTTP Request Smuggler" inclui uma sonda de estado de conexão que automatiza isso.
+5. Visualize o fio
+- Use a extensão Burp "HTTP Hacker" para inspecionar a concatenação e o enquadramento de mensagens diretamente enquanto experimenta com reutilização e solicitações parciais.
+
+### Smuggling de requisições bloqueadas por conexão (reutilização necessária)
+
+Alguns front-ends só reutilizam a conexão upstream quando o cliente reutiliza a sua. O smuggling real existe, mas é condicional à reutilização do lado do cliente. Para distinguir e provar o impacto:
+- Prove o bug do lado do servidor
+- Use a verificação de resposta aninhada HTTP/2, ou
+- Use solicitações parciais para mostrar que o FE só reutiliza upstream quando o cliente o faz.
+- Mostre impacto real, mesmo que o abuso direto de socket entre usuários esteja bloqueado:
+- Envenenamento de cache: envenene caches compartilhados via a desincronização para que as respostas afetem outros usuários.
+- Divulgação de cabeçalho interno: reflita cabeçalhos injetados pelo FE (por exemplo, cabeçalhos de autenticação/confiança) e pivote para bypass de autenticação.
+- Bypass de controles do FE: smuggle caminhos/métodos restritos além do front-end.
+- Abuso de cabeçalho de host: combine com peculiaridades de roteamento de host para pivotar para vhosts internos.
+- Fluxo de trabalho do operador
+- Reproduza com reutilização controlada (Turbo Intruder `requestsPerConnection=2`, ou grupo de guia Burp Repeater → "Enviar grupo em sequência (conexão única)").
+- Em seguida, encadeie para primitivas de envenenamento de cache/divulgação de cabeçalho/bypass de controle e demonstre impacto entre usuários ou de autorização.
+
+> Veja também ataques de estado de conexão, que estão intimamente relacionados, mas não são tecnicamente smuggling:
+>
+>{{#ref}}
+>../http-connection-request-smuggling.md
+>{{#endref}}
+
+### Restrições de desincronização do lado do cliente
+
+Se você está mirando desincronização do lado do cliente/poderada pelo navegador, a solicitação maliciosa deve ser enviável por um navegador cross-origin. Truques de ofuscação de cabeçalho não funcionarão. Concentre-se em primitivas acessíveis via navegação/fetch e, em seguida, pivote para envenenamento de cache, divulgação de cabeçalho ou bypass de controle do front-end onde componentes downstream refletem ou armazenam em cache respostas.
+
+Para contexto e fluxos de trabalho de ponta a ponta:
+
+{{#ref}}
+-browser-http-request-smuggling.md
+{{#endref}}
+
+### Ferramentas para ajudar a decidir
+
+- HTTP Hacker (Burp BApp Store): expõe comportamento HTTP de baixo nível e concatenação de socket.
+- "Smuggling ou pipelining?" Ação Personalizada do Burp Repeater: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
+- Turbo Intruder: controle preciso sobre a reutilização de conexão via `requestsPerConnection`.
+- Burp HTTP Request Smuggler: inclui uma sonda de estado de conexão para detectar roteamento/validação da primeira solicitação.
+
+> [!NOTE]
+> Trate efeitos apenas de reutilização como não problemas, a menos que você possa provar desincronização do lado do servidor e anexar impacto concreto (artefato de cache envenenado, cabeçalho interno vazado permitindo bypass de privilégio, controle do FE contornado, etc.).
+
+## Abusando do HTTP Request Smuggling
 
 ### Contornando a Segurança do Front-End via HTTP Request Smuggling
 
-Às vezes, proxies front-end impõem medidas de segurança, examinando solicitações de entrada. 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. No entanto, esse proxy pode negligenciar inspecionar solicitações embutidas dentro de uma solicitação HTTP contrabandeada, deixando uma brecha para contornar essas restrições.
+Às vezes, proxies de front-end impõem medidas de segurança, examinando solicitações de entrada. No entanto, essas medidas podem ser contornadas explorando o HTTP Request Smuggling, permitindo acesso não autorizado a endpoints restritos. Por exemplo, acessar `/admin` pode ser proibido externamente, com o proxy de front-end bloqueando ativamente tais tentativas. No entanto, esse proxy pode negligenciar inspecionar solicitações embutidas dentro de uma solicitação HTTP smuggled, deixando uma brecha para contornar essas restrições.
 
-Considere os seguintes exemplos que ilustram como HTTP Request Smuggling pode ser usado para contornar controles de segurança do front-end, especificamente visando o caminho `/admin`, que geralmente é protegido pelo proxy front-end:
+Considere os seguintes exemplos que ilustram como o HTTP Request Smuggling pode ser usado para contornar controles de segurança do front-end, especificamente visando o caminho `/admin`, que é tipicamente protegido pelo proxy de front-end:
 
 **Exemplo CL.TE**
 ```
@@ -302,7 +408,7 @@ Content-Length: 10
 
 x=
 ```
-No ataque CL.TE, o cabeçalho `Content-Length` é utilizado para a solicitação inicial, enquanto a solicitação incorporada subsequente utiliza o cabeçalho `Transfer-Encoding: chunked`. O proxy de front-end processa a solicitação `POST` inicial, mas falha em inspecionar a solicitação incorporada `GET /admin`, permitindo acesso não autorizado ao caminho `/admin`.
+No ataque CL.TE, o cabeçalho `Content-Length` é utilizado para a solicitação inicial, enquanto a solicitação embutida subsequente utiliza o cabeçalho `Transfer-Encoding: chunked`. O proxy de front-end processa a solicitação `POST` inicial, mas falha em inspecionar a solicitação embutida `GET /admin`, permitindo acesso não autorizado ao caminho `/admin`.
 
 **TE.CL Exemplo**
 ```
@@ -324,7 +430,7 @@ Por outro lado, no ataque TE.CL, a requisição inicial `POST` utiliza `Transfer
 
 ### Revelando reescrita de requisições de front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
 
-As aplicações frequentemente utilizam um **servidor de front-end** para modificar requisições recebidas antes de passá-las para o servidor de back-end. Uma modificação típica envolve adicionar cabeçalhos, como `X-Forwarded-For: <IP do cliente>`, para relatar o IP do cliente ao back-end. Compreender essas modificações pode ser crucial, pois pode revelar maneiras de **contornar proteções** ou **descobrir informações ou endpoints ocultos**.
+As aplicações frequentemente utilizam um **servidor de front-end** para modificar requisições recebidas antes de passá-las para o servidor de back-end. Uma modificação típica envolve a adição de cabeçalhos, como `X-Forwarded-For: <IP do cliente>`, para relatar o IP do cliente ao back-end. Compreender essas modificações pode ser crucial, pois pode revelar maneiras de **contornar proteções** ou **descobrir informações ou endpoints ocultos**.
 
 Para investigar como um proxy altera uma requisição, localize um parâmetro POST que o back-end ecoa na resposta. Em seguida, elabore uma requisição, usando este parâmetro por último, semelhante ao seguinte:
 ```
@@ -343,13 +449,13 @@ Content-Length: 100
 
 search=
 ```
-Nesta estrutura, os componentes de solicitação subsequentes são anexados após `search=`, que é o parâmetro refletido na resposta. Essa reflexão exporá os cabeçalhos da solicitação subsequente.
+Nesta estrutura, os componentes subsequentes da solicitação são anexados após `search=`, que é o parâmetro refletido na resposta. Essa reflexão exporá os cabeçalhos da solicitação subsequente.
 
 É importante alinhar o cabeçalho `Content-Length` da solicitação aninhada com o comprimento real do conteúdo. Começar com um valor pequeno e aumentar gradualmente é aconselhável, pois um valor muito baixo truncará os dados refletidos, enquanto um valor muito alto pode causar um erro na solicitação.
 
 Essa técnica também é aplicável no contexto de uma vulnerabilidade TE.CL, mas a solicitação deve terminar com `search=\r\n0`. Independentemente dos caracteres de nova linha, os valores serão anexados ao parâmetro de busca.
 
-Este método serve principalmente para entender as modificações na solicitação feitas pelo proxy de front-end, essencialmente realizando uma investigação autodirigida.
+Este método serve principalmente para entender as modificações na solicitação feitas pelo proxy do front-end, essencialmente realizando uma investigação autodirigida.
 
 ### Capturando as solicitações de outros usuários <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
 
@@ -377,7 +483,7 @@ csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40ema
 ```
 Neste cenário, o **parâmetro de comentário** destina-se a armazenar o conteúdo na seção de comentários de um post em uma página acessível publicamente. Consequentemente, o conteúdo da solicitação subsequente aparecerá como um comentário.
 
-No entanto, essa técnica tem limitações. Geralmente, captura dados apenas até o delimitador de parâmetro usado na solicitação contrabandeada. Para envios de formulários codificados em URL, esse delimitador é o caractere `&`. Isso significa que o conteúdo capturado da solicitação do usuário vítima parará no primeiro `&`, que pode até fazer parte da string de consulta.
+No entanto, essa técnica tem limitações. Geralmente, ela captura dados apenas até o delimitador de parâmetro usado na solicitação contrabandeada. Para envios de formulários codificados em URL, esse delimitador é o caractere `&`. Isso significa que o conteúdo capturado da solicitação do usuário vítima parará no primeiro `&`, que pode até fazer parte da string de consulta.
 
 Além disso, vale a pena notar que essa abordagem também é viável com uma vulnerabilidade TE.CL. Nesses casos, a solicitação deve terminar com `search=\r\n0`. Independentemente dos caracteres de nova linha, os valores serão anexados ao parâmetro de busca.
 
@@ -424,7 +530,7 @@ Ao manipular o `User-Agent` através do smuggling, o payload contorna as restri
 
 A versão HTTP/0.9 era anterior à 1.0 e usa apenas verbos **GET** e **não** responde com **cabeçalhos**, apenas o corpo.
 
-Em [**este writeup**](https://mizu.re/post/twisty-python), isso foi abusado com um smuggling de requisição e um **endpoint vulnerável que irá responder com a entrada do usuário** para smuggling uma requisição com HTTP/0.9. O parâmetro que será refletido na resposta continha uma **resposta HTTP/1.1 falsa (com cabeçalhos e corpo)**, de modo que a resposta conterá código JS executável válido com um `Content-Type` de `text/html`.
+Em [**este writeup**](https://mizu.re/post/twisty-python), isso foi abusado com um smuggling de requisição e um **endpoint vulnerável que irá responder com a entrada do usuário** para smugar uma requisição com HTTP/0.9. O parâmetro que será refletido na resposta continha uma **resposta HTTP/1.1 falsa (com cabeçalhos e corpo)**, de modo que a resposta conterá código JS executável válido com um `Content-Type` de `text/html`.
 
 ### Explorando Redirecionamentos no Local com HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
 
@@ -492,13 +598,13 @@ Content-Length: 10
 
 x=1
 ```
-Note o pedido embutido direcionado a `/post/next?postId=3`. Este pedido será redirecionado para `/post?postId=4`, utilizando o **valor do cabeçalho Host** para determinar o domínio. Ao alterar o **cabeçalho Host**, o atacante pode redirecionar o pedido para seu domínio (**redirecionamento no site para redirecionamento aberto**).
+Note o pedido incorporado direcionado a `/post/next?postId=3`. Este pedido será redirecionado para `/post?postId=4`, utilizando o **valor do cabeçalho Host** para determinar o domínio. Ao alterar o **cabeçalho Host**, o atacante pode redirecionar o pedido para seu domínio (**redirecionamento no site para redirecionamento aberto**).
 
 Após um **envenenamento de socket** bem-sucedido, um **pedido GET** para `/static/include.js` deve ser iniciado. Este pedido será contaminado pelo anterior pedido de **redirecionamento no site para redirecionamento aberto** e buscará o conteúdo do script controlado pelo atacante.
 
 Subsequentemente, qualquer pedido para `/static/include.js` servirá o conteúdo em cache do script do atacante, efetivamente lançando um amplo ataque XSS.
 
-### Usando o HTTP request smuggling para realizar engano de cache web <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
+### Usando HTTP request smuggling para realizar engano de cache web <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 envenenamento de cache web e engano de cache web?**
 >
@@ -516,7 +622,7 @@ O atacante cria um pedido contrabandeado que busca conteúdo sensível específi
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-Se esta solicitação contrabandeada 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 em cache sob a entrada de cache do conteúdo estático. Consequentemente, o atacante poderia potencialmente recuperar esses dados sensíveis armazenados em cache.
+Se esta solicitação contrabandeada 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 em cache 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>
 
@@ -526,7 +632,7 @@ TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Claro! Por favor, envie o texto que você gostaria que eu traduzisse.
+Claro! Por favor, envie o conteúdo que você gostaria que eu traduzisse.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@@ -537,15 +643,15 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-Um exemplo de como abusar desse comportamento seria **contrabandear primeiro um pedido HEAD**. Este pedido será respondido apenas com os **cabeçalhos** de um pedido GET (**`Content-Type`** entre eles). E contrabandear **imediatamente após o HEAD um pedido TRACE**, que irá **refletir os dados enviados**.\
-Como a resposta do HEAD conterá um cabeçalho `Content-Length`, a **resposta do pedido TRACE será tratada como o corpo da resposta HEAD, refletindo assim dados arbitrários** na resposta.\
-Essa resposta será enviada para o próximo pedido sobre a 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 **contrabandear primeiro uma solicitação HEAD**. Esta solicitação será respondida apenas com os **cabeçalhos** de uma solicitação GET (**`Content-Type`** entre eles). E contrabandear **imediatamente após o HEAD uma solicitação TRACE**, que irá **refletir os dados enviados**.\
+Como a resposta do HEAD conterá um cabeçalho `Content-Length`, a **resposta da solicitação TRACE será tratada como o corpo da resposta HEAD, refletindo assim dados arbitrários** na resposta.\
+Essa resposta será enviada para a próxima solicitação sobre a conexão, então isso poderia ser **usado em um arquivo JS em cache, por exemplo, para injetar código JS arbitrário**.
 
 ### Abusando do TRACE via Splitting de Resposta HTTP <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
 
-Continuar seguindo [**este post**](https://portswigger.net/research/trace-desync-attack) sugere outra maneira de abusar do método TRACE. Como comentado, contrabandeando um pedido HEAD e um pedido TRACE, é possível **controlar alguns dados refletidos** na resposta ao pedido HEAD. O comprimento do corpo do pedido HEAD é basicamente indicado no cabeçalho Content-Length e é formado pela resposta ao pedido TRACE.
+Continuar seguindo [**este post**](https://portswigger.net/research/trace-desync-attack) sugere outra maneira de abusar do método TRACE. Como comentado, contrabandear uma solicitação HEAD e uma solicitação TRACE torna possível **controlar alguns dados refletidos** na resposta à solicitação HEAD. O comprimento do corpo da solicitação HEAD é basicamente indicado no cabeçalho Content-Length e é formado pela resposta à solicitação TRACE.
 
-Portanto, a nova ideia seria que, sabendo esse Content-Length e os dados fornecidos na resposta TRACE, é possível fazer com que a resposta TRACE contenha uma resposta HTTP válida após o último byte do Content-Length, permitindo que um atacante controle completamente o pedido para a próxima resposta (o que poderia ser usado para realizar um envenenamento de cache).
+Portanto, a nova ideia seria que, sabendo esse Content-Length e os dados fornecidos na resposta TRACE, é possível fazer com que a resposta TRACE contenha uma resposta HTTP válida após o último byte do Content-Length, permitindo que um atacante controle completamente a solicitação para a próxima resposta (o que poderia ser usado para realizar um envenenamento de cache).
 
 Exemplo:
 ```
@@ -566,7 +672,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-Gerará essas respostas (note como a resposta HEAD tem um Content-Length, fazendo com que a resposta TRACE faça parte do corpo da HEAD e, uma vez que o Content-Length da HEAD termina, uma resposta HTTP válida é escondida):
+Gerará essas respostas (note como a resposta HEAD tem um Content-Length, fazendo com que a resposta TRACE faça parte do corpo do HEAD e, uma vez que o Content-Length do HEAD termina, uma resposta HTTP válida é contrabandeada):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -698,6 +804,8 @@ table.add(req)
 ```
 ## Ferramentas
 
+- HTTP Hacker (Burp BApp Store) – visualize concatenação/framing e comportamento HTTP de baixo nível
+- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Ação Personalizada do Burp Repeater "Smuggling ou 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)
@@ -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 com o falso positivo: como distinguir HTTP pipelining de 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 Desync Potencializados por Navegador – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
+- PortSwigger Academy – desync do lado do 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}}

src/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md

@@ -2,6 +2,22 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-**Verifique o post [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)**
+Browser-powered desync (também conhecido como client-side request smuggling) explora o navegador da vítima para enfileirar uma solicitação mal formatada em uma conexão compartilhada, de modo que solicitações subsequentes sejam analisadas fora de sincronia por um componente a jusante. Ao contrário do smuggling clássico FE↔BE, os payloads são limitados pelo que um navegador pode legalmente enviar entre origens.
+
+Principais restrições e dicas
+- Use apenas cabeçalhos e sintaxe que um navegador pode emitir via navegação, fetch ou envio de formulários. Ofuscações de cabeçalho (truques LWS, TE duplicado, CL inválido) geralmente não serão enviadas.
+- Alvo de endpoints e intermediários que refletem entradas ou armazenam respostas em cache. Impactos úteis incluem envenenamento de cache, vazamento de cabeçalhos injetados no front-end ou contorno de controles de caminho/método do front-end.
+- A reutilização importa: alinhe a solicitação elaborada para que compartilhe a mesma conexão HTTP/1.1 ou H2 que uma solicitação de vítima de alto valor. Comportamentos bloqueados por conexão/estaduais amplificam o impacto.
+- Prefira primitivas que não exijam cabeçalhos personalizados: confusão de caminho, injeção de string de consulta e modelagem de corpo via POSTs codificados em formulário.
+- Valide a verdadeira desincronização do lado do servidor em comparação com meros artefatos de pipeline, re-testando sem reutilização ou usando a verificação de resposta aninhada do HTTP/2.
+
+Para técnicas de ponta a ponta e PoCs, veja:
+- PortSwigger Research – Browser‑Powered Desync Attacks: https://portswigger.net/research/browser-powered-desync-attacks
+- PortSwigger Academy – client‑side desync: https://portswigger.net/web-security/request-smuggling/browser/client-side-desync
+
+## References
+- [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
+- [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
+- Distinguishing pipelining vs smuggling (background on reuse false-positives): https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling
 
 {{#include ../../banners/hacktricks-training.md}}