O contrabando de solicitações HTTP ( HRS ) é uma exploração de segurança no protocolo HTTP que tira proveito de uma inconsistência entre a interpretação dos cabeçalhos Content-Length e Transfer-Encoding entre implementações de servidores HTTP em uma cadeia de servidores proxy HTTP . Foi documentado pela primeira vez em 2005 por Linhart et al.

O cabeçalho Transfer-Encoding funciona definindo uma diretiva sobre como interpretar o corpo da solicitação HTTP, com a diretiva comum e necessária para esse ataque sendo a codificação de transferência em blocos . Quando o cabeçalho Transfer-Encoding está presente, o cabeçalho Content-Length deve ser omitido. Funcionando de forma semelhante, mas com uma sintaxe diferente, o cabeçalho Content-Length funciona especificando o tamanho em bytes do corpo como um valor no próprio cabeçalho. Vulnerabilidades surgem quando ambos os cabeçalhos são incluídos em uma solicitação HTTP maliciosa, ignorando funções de segurança destinadas a evitar consultas HTTP maliciosas ao servidor, fazendo com que o servidor front-end ou back-end interprete incorretamente a solicitação.

Tipos

CL.TE Neste tipo de contrabando de solicitações HTTP, o front-end processa a solicitação usando o cabeçalho Content-Length, enquanto o back-end processa a solicitação usando o cabeçalho Transfer-Encoding. O ataque seria realizado com a primeira parte da solicitação declarando um pedaço de comprimento zero. O servidor front-end vendo isso leria apenas a primeira parte da solicitação e passaria involuntariamente a segunda parte para o servidor back-end. Uma vez passado para o servidor back-end, ele seria tratado como a próxima solicitação e processado, executando a solicitação oculta dos invasores.

TE.CL Neste tipo de contrabando de solicitação HTTP, o front-end processa a solicitação usando o cabeçalho Transfer-Encoding enquanto o back-end processa a solicitação usando o cabeçalho Content-Length. Neste ataque, um hacker declararia o comprimento válido do primeiro pedaço, que abriga a solicitação maliciosa e, em seguida, declararia um segundo pedaço com comprimento 0. Quando o servidor front-end vê o segundo pedaço com comprimento 0, ele acredita que a solicitação foi concluída e o passa para o servidor back-end. O servidor back-end processa a solicitação usando o cabeçalho Content-Length, no entanto, e como resultado, a solicitação maliciosa deixada no primeiro pedaço não é processada até que seja tratada como estando no início da próxima solicitação na sequência e seja executada.

TE.TE Neste tipo de contrabando de solicitações HTTP, o front-end e o back-end processam a solicitação usando o cabeçalho Transfer-Encoding, mas o cabeçalho pode ser ofuscado de uma forma (por exemplo, por formatação de espaço em branco não padrão ou cabeçalhos duplicados) que faz com que um dos servidores, mas não o outro, o ignore. Obscurecer o cabeçalho pode assumir a forma de adicionar um caractere incorreto, como Transfer-Encoding: xchunked, ou um caractere de nova linha incomum entre 'Transfer-Encoding' e ': chunked'. Se um dos servidores front-end ou back-end ainda processar essas solicitações HTTP ofuscadas, o resto do ataque será semelhante a como funcionam os ataques CL.TE ou TE.CL.

Prevenção A melhor prevenção contra esses ataques seria claramente se os servidores front-end e back-end interpretassem as solicitações HTTP da mesma forma. No entanto, isso geralmente não é uma opção, pois os balanceadores de carga permitem que os servidores back-end sejam executados em plataformas distintas, usando softwares diferentes. A maioria das variantes desse ataque pode ser prevenido usando HTTP/2, pois ele usa um método diferente para determinar o comprimento de uma solicitação. Outro método para evitar o ataque é o servidor frontend normalizar as solicitações HTTP antes de passá-las para o backend, garantindo que sejam interpretadas da mesma maneira. Configurar um firewall de aplicativo web é outra boa maneira de prevenir ataques HRS, pois muitos apresentam tecnologias que identificam tentativas de ataque e bloqueiam ou higienizam as solicitações suspeitas recebidas.

Grenfeldt et al. (2021) descobriram que a maioria dos servidores web front-end (por exemplo, servidores proxy) forneciam recursos de análise para impedir, na prática, todos os ataques HRS conhecidos nos servidores web back-end. Huang et al. (2022) propuseram um método usando Flask para implementar recursos de análise adequados que evitassem ataques HRS, de um programa front-end ou servidor web.

Referências

Categoria:Explorações de segurança da Web