diff --git a/src/pentesting-web/http-request-smuggling/README.md b/src/pentesting-web/http-request-smuggling/README.md index 2cb3a7975..3d90c40fa 100644 --- a/src/pentesting-web/http-request-smuggling/README.md +++ b/src/pentesting-web/http-request-smuggling/README.md @@ -40,7 +40,7 @@ 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 pelos servidores de maneiras diferentes, 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 de maneiras diferentes pelos servidores, levando a resultados inesperados e potencialmente maliciosos. ### Exemplos Básicos de Tipos de Vulnerabilidade @@ -79,7 +79,7 @@ Foo: x - **Back-End (CL):** Processa a requisição com base no cabeçalho `Content-Length`. - **Cenário de Ataque:** -- O atacante envia uma requisição chunked onde o tamanho do pedaço (`7b`) e o comprimento real do conteúdo (`Content-Length: 4`) não se alinham. +- O atacante envia uma requisição chunked onde o tamanho do pedaço (`7b`) e o comprimento real do conteúdo (`Content-Length: 4`) não estão alinhados. - O servidor de front-end, respeitando `Transfer-Encoding`, encaminha toda a requisição para o back-end. - O servidor 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:** @@ -185,7 +185,7 @@ EMPTY_LINE_HERE 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 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**. +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 @@ -272,7 +272,7 @@ 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:** 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. +- **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 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. @@ -333,16 +333,16 @@ Impacto: nenhum. Você apenas desincronizou seu cliente do enquadramento do serv - 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 +3. Sondagem 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 +4. Sondagens 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. +- O Burp "HTTP Request Smuggler" inclui uma sondagem 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) +### Solicitação de smuggling bloqueada 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 @@ -370,7 +370,7 @@ Se você está mirando desincronização do lado do cliente/poderada pelo navega Para contexto e fluxos de trabalho de ponta a ponta: {{#ref}} --browser-http-request-smuggling.md +browser-http-request-smuggling.md {{#endref}} ### Ferramentas para ajudar a decidir @@ -378,10 +378,10 @@ Para contexto e fluxos de trabalho de ponta a ponta: - 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. +- Burp HTTP Request Smuggler: inclui uma sondagem 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.). +> Trate os 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 @@ -426,13 +426,13 @@ a=x 0 ``` -Por outro lado, no ataque TE.CL, a requisição inicial `POST` utiliza `Transfer-Encoding: chunked`, e a requisição embutida subsequente é processada com base no cabeçalho `Content-Length`. Semelhante ao ataque CL.TE, o proxy de front-end ignora a requisição `GET /admin` contrabandeada, concedendo inadvertidamente acesso ao caminho restrito `/admin`. +Por outro lado, no ataque TE.CL, a solicitação inicial `POST` usa `Transfer-Encoding: chunked`, e a solicitação embutida subsequente é processada com base no cabeçalho `Content-Length`. Semelhante ao ataque CL.TE, o proxy de front-end ignora a solicitação `GET /admin` contrabandeada, concedendo inadvertidamente acesso ao caminho restrito `/admin`. -### Revelando reescrita de requisições de front-end +### Revelando reescrita de solicitaçõ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 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**. +As aplicações frequentemente utilizam um **servidor de front-end** para modificar solicitaçõ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: +Para investigar como um proxy altera uma solicitação, localize um parâmetro POST que o back-end ecoa na resposta. Em seguida, elabore uma solicitação, usando este parâmetro por último, semelhante ao seguinte: ``` POST / HTTP/1.1 Host: vulnerable-website.com @@ -455,7 +455,7 @@ Nesta estrutura, os componentes subsequentes da solicitação são anexados apó 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 do front-end, essencialmente realizando uma investigação autodirigida. +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. ### Capturando as solicitações de outros usuários @@ -532,7 +532,7 @@ A versão HTTP/0.9 era anterior à 1.0 e usa apenas verbos **GET** e **não** re 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 +### Explorando Redirecionamentos no Site com HTTP Request Smuggling As aplicações frequentemente redirecionam de uma URL para outra usando o hostname do cabeçalho `Host` na URL de redirecionamento. Isso é comum em servidores web como Apache e IIS. Por exemplo, solicitar uma pasta sem uma barra no final resulta em um redirecionamento para incluir a barra: ``` @@ -572,15 +572,15 @@ Location: https://attacker-website.com/home/ ``` Neste cenário, o pedido de um usuário por um arquivo JavaScript é sequestrado. O atacante pode potencialmente comprometer o usuário servindo JavaScript malicioso em resposta. -### Explorando a Contaminação de Cache Web via HTTP Request Smuggling +### Exploração de Envenenamento de Cache Web via HTTP Request Smuggling -A contaminação de cache web pode ser executada se qualquer componente da **infraestrutura de front-end armazenar conteúdo em cache**, tipicamente para melhorar o desempenho. Ao manipular a resposta do servidor, é possível **contaminar o cache**. +O envenenamento de cache web pode ser executado se qualquer componente da **infraestrutura de front-end armazenar conteúdo em cache**, tipicamente para melhorar o desempenho. Ao manipular a resposta do servidor, é possível **envenenar o cache**. Anteriormente, observamos como as respostas do servidor poderiam ser alteradas para retornar um erro 404 (consulte [Exemplos Básicos](#basic-examples)). Da mesma forma, é viável enganar o servidor para entregar o conteúdo de `/index.html` em resposta a um pedido 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, potencialmente levando a uma Negação de Serviço (DoS). Essa técnica se torna particularmente poderosa se uma **vulnerabilidade de Redirecionamento Aberto** for descoberta ou se houver um **redirecionamento no site para um redirecionamento aberto**. Tais vulnerabilidades podem ser exploradas para substituir o conteúdo em cache de `/static/include.js` por um script sob o controle do atacante, essencialmente permitindo um ataque generalizado de Cross-Site Scripting (XSS) contra todos os clientes que solicitam o `/static/include.js` atualizado. -Abaixo está uma ilustração da exploração de **contaminação de cache combinada com um redirecionamento no site para redirecionamento aberto**. O objetivo é alterar o conteúdo do cache de `/static/include.js` para servir código JavaScript controlado pelo atacante: +Abaixo está uma ilustração da exploração de **envenenamento de cache combinado com um redirecionamento no site para redirecionamento aberto**. 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 @@ -598,7 +598,7 @@ Content-Length: 10 x=1 ``` -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**). +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**). 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. @@ -611,7 +611,7 @@ Subsequentemente, qualquer pedido para `/static/include.js` servirá o conteúdo > - No **envenenamento de cache web**, o atacante faz com que a aplicação armazene algum conteúdo malicioso no cache, e esse conteúdo é servido do cache para outros usuários da aplicação. > - No **engano de cache web**, o atacante faz com que a aplicação armazene algum conteúdo sensível pertencente a outro usuário no cache, e o atacante então recupera esse conteúdo do cache. -O atacante cria um pedido contrabandeado que busca conteúdo sensível específico do usuário. Considere o seguinte exemplo: +O atacante elabora um pedido contrabandeado que busca conteúdo sensível específico do usuário. Considere o seguinte exemplo: ```markdown `POST / HTTP/1.1`\ `Host: vulnerable-website.com`\ @@ -643,15 +643,15 @@ Host: vulnerable.com XSS: X-Forwarded-For: xxx.xxx.xxx.xxx ``` -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**. +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**. -### Abusando do TRACE via Splitting de Resposta HTTP +### Abusando do TRACE via HTTP Response Splitting -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. +Continue seguindo [**este post**](https://portswigger.net/research/trace-desync-attack) que sugere outra maneira de abusar do método TRACE. Como comentado, contrabandear um pedido HEAD e um pedido TRACE torna 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. -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). +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). Exemplo: ``` @@ -693,7 +693,7 @@ Content-Length: 50 ``` -### Armando HTTP Request Smuggling com Desincronização de Resposta HTTP +### Armazenando HTTP Request Smuggling com Desincronização de Resposta HTTP Você encontrou alguma vulnerabilidade de HTTP Request Smuggling e não sabe como explorá-la. Tente este outro método de exploração: