detalhes de um novo ataque a sites que usam um modelo front-end-back-end, como aqueles executados em redes de entrega de conteúdo, balanceadores de carga ou proxies. O ataque permite, ao enviar certas solicitações, penetrar no conteúdo de outras solicitações processadas no mesmo thread entre o frontend e o backend. O método proposto foi utilizado com sucesso para organizar um ataque que permitiu interceptar os parâmetros de autenticação dos usuários do serviço PayPal, que pagou aos pesquisadores cerca de 40 mil dólares como parte de um programa para informar sobre a presença de vulnerabilidades não corrigidas. O ataque também se aplica a sites que usam a rede de distribuição de conteúdo Akamai.
O cerne do problema é que front-ends e back-ends geralmente fornecem diferentes níveis de suporte para o protocolo HTTP, mas ao mesmo tempo encapsulam solicitações de diferentes usuários em um canal comum. Para conectar as solicitações de recebimento de frontend e as solicitações de processamento de backend, é estabelecida uma conexão TCP de longa duração, por meio da qual são transmitidas as solicitações do usuário, transmitidas ao longo da cadeia uma após a outra, separadas por meio do protocolo HTTP. Para separar as solicitações, os cabeçalhos "Content-Length" (determina o tamanho total dos dados na solicitação) e ""(permite transferir dados em partes, especificando blocos de tamanhos diferentes no formato "{tamanho}\r\n{bloco}\r\n{tamanho}\r\n{bloco}\r\n0").
O problema surge se o frontend suporta apenas “Content-Length”, mas ignora “Transfer-Encoding: chunked” (por exemplo, Akamai CDN fez isso) ou vice-versa. Se Transfer-Encoding: chunked for suportado em ambos os lados, os recursos de implementação dos analisadores de cabeçalho HTTP podem ser usados para um ataque (por exemplo, quando o front end ignora linhas como “Transfer-Encoding: xchunked”, “Transfer-Encoding: chunked ”, “Codificação de transferência” :[tab]chunked", "X: X[\n]Transfer-Encoding: chunked", "Transfer-Encoding[\n]: chunked" ou "Transfer-Encoding : chunked", e o backend os processa com sucesso).
Nesse caso, um invasor pode enviar uma solicitação que contenha os cabeçalhos "Content-Length" e "Transfer-Encoding: chunked", mas o tamanho em "Content-Length" não corresponde ao tamanho da cadeia fragmentada, que é menor que o valor real. Se o frontend processar e encaminhar a solicitação de acordo com "Content-Length" e o backend aguardar a conclusão do bloco com base em "Transfer-Encoding: chunked", então o final dos dados com base em "Transfer-Encoding: chunked" será será determinado anteriormente e o restante da solicitação que o invasor estará no início da próxima solicitação, ou seja, o invasor poderá anexar dados arbitrários ao início da solicitação de outra pessoa transmitida a seguir.
Para determinar o problema na combinação frontend-backend usada, você pode enviar uma solicitação como esta através do frontend:
POSTAR/sobre HTTP/1.1
Anfitrião: example.com
Codificação de transferência: fragmentada
Content-Length: 4
1
Z
Q
O problema estará presente se o back-end não processar imediatamente a solicitação e aguardar a chegada do bloco final de dados fragmentados com limite zero. Para uma verificação mais completa um utilitário especial que também testa possíveis métodos para ocultar o cabeçalho “Transfer-Encoding: chunked” do frontend.
A realização de um ataque real depende das capacidades do site atacado, por exemplo, ao atacar a aplicação web Trello, você pode substituir o início da solicitação (substituir dados como “PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) e enviar uma mensagem incluindo a solicitação original de um usuário terceiro e o cookie de autenticação especificado nela. Para um ataque ao saas-app.com, foi possível substituir o código JavaScript na resposta, substituindo-o em um dos parâmetros da solicitação. Para o ataque ao redhat.com, um manipulador interno foi usado para redirecionar para o site do invasor (uma solicitação no formato “POST /search?dest=../assets/idx?redir=//[email protegido]/HTTP/1.1").
A utilização do método para redes de distribuição de conteúdo possibilitou simplesmente substituir o site solicitado, substituindo o cabeçalho “Host:”. O ataque também pode ser usado para envenenar o conteúdo dos sistemas de cache de conteúdo e extrair dados confidenciais armazenados em cache. O ápice do método foi a organização de um ataque ao PayPal, que possibilitou a interceptação de senhas enviadas pelos usuários durante a autenticação (a solicitação iframe foi modificada para executar JavaScript no contexto da página paypal.com/us/gifts, por qual CSP (Política de Segurança de Conteúdo) não foi aplicada).
Curiosamente, em 2005 houve uma técnica de falsificação de solicitação essencialmente semelhante que permite falsificar dados em proxies de cache (Tomcat, squid, mod_proxy) ou ignorar o bloqueio de firewall especificando várias solicitações “GET” ou “POST” em uma sessão HTTP.
Fonte: opennet.ru