mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/http-request-smuggling/README.md'] to pt
This commit is contained in:
Translator
parent
a1556a02b5
commit
dfc8219b91
@ -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 <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
|
||||
### Revelando reescrita de solicitaçõ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 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**.
|
||||
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: <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:
|
||||
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 <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
||||
|
||||
@ -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 <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
### Explorando Redirecionamentos no 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>
|
||||
|
||||
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 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
### Exploração de Envenenamento de Cache Web via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
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: <script>alert("TRACE")</script>
|
||||
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 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
### Abusando do 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 [**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
|
||||
|
||||
<script>alert(“arbitrary response”)</script>
|
||||
```
|
||||
### 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:
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user