diff --git a/src/pentesting-web/http-request-smuggling/README.md b/src/pentesting-web/http-request-smuggling/README.md index 6af5b8299..2cb3a7975 100644 --- a/src/pentesting-web/http-request-smuggling/README.md +++ b/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 -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: `, 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: `, 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 @@ -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 @@ -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 +### Usando HTTP request smuggling para realizar engano de cache web > **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 @@ -526,7 +632,7 @@ TRACE / HTTP/1.1 Host: example.com XSS: ``` -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: 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 -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 ``` -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}} diff --git a/src/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md b/src/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md index 847c0b9dd..27068dfc2 100644 --- a/src/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md +++ b/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}}