Os riscos de usar HTTP estão aumentando, mas são gerenciáveis

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Gostemos ou não, o HTTP é, na prática, o protocolo de transporte de aplicações da era moderna. Nós o usamos em todos os lugares. Ele é tão onipresente quanto o IP e o TCP e cumpre praticamente a mesma função. Seu único objetivo é transportar o ouro digital dos negócios atuais: os dados.

Não importa se esses dados estão em JSON, XML ou codificados para uso em URLs. É o HTTP que aplicativos e dispositivos usam para se comunicar com servidores e serviços na nuvem e localmente no data center.

No entanto, diferentemente do IP e do TCP, o HTTP é um protocolo baseado em texto. Ele é altamente flexível e pode transportar diversos tipos de dados — de binários a texto. Nós o utilizamos para transmitir, recuperar e coletar dados.

Os invasores o utilizam amplamente porque, como mencionado, trata-se de um protocolo baseado em texto, com regras bastante flexíveis quanto às extensões dos cabeçalhos que especificam desde a ação que o cliente espera que o servidor execute (o “método” HTTP), passando pelo recurso solicitado (o URI), até o tipo de conteúdo que pode ser aceito (os cabeçalhos “Accept”). Essas regras são flexíveis para permitir a extensibilidade.

Por exemplo, o cabeçalho X-Forwarded-For foi introduzido para garantir que os desenvolvedores pudessem “ver” o endereço IP original do cliente. Em determinadas arquiteturas — especialmente aquelas em que os intermediários atuam como proxies completos —, essa informação pode ser perdida. Algumas aplicações precisam desses dados e, por isso, os desenvolvedores (e fornecedores de soluções de rede) ampliaram o protocolo HTTP com a introdução de um cabeçalho personalizado. Isso faz parte da especificação HTTP e permite inovar e introduzir novos comportamentos e recursos sem exigir alterações no protocolo. É algo positivo.

Exceto quando não é.

Não é bom quando essa flexibilidade não é levada em consideração pelos desenvolvedores dos servidores que oferecem suporte a HTTP ou pelos responsáveis por proteger aplicações que dependem de HTTP.

Veja uma pequena amostra de CVEs relacionados ao HTTP que exploram uma vulnerabilidade nos cabeçalhos HTTP:

Sinceramente, uma busca entre as CVEs conhecidas por vulnerabilidades de HTTP retorna uma lista excessivamente longa (que inclui uma grande variedade de fornecedores e softwares), que não vou reproduzir aqui. Uma parcela significativa dessas vulnerabilidades geralmente é explorada por meio do uso indevido de um cabeçalho HTTP.

Uma observação sobre o Optionsbleed

Optionsbleed é uma das vulnerabilidades mais recentes. Eu a destaco porque ela existe no próprio Apache HTTP. Considerando que, segundo as estimativas atuais da Netcraft, “mais de 2,8 milhões de computadores voltados para a web executam atualmente várias versões e derivados do Apache httpd, o que lhe confere uma participação de 42,8% entre todos os computadores voltados para a web”, as vulnerabilidades nele representam um risco significativo. Felizmente, essa vulnerabilidade específica é acionada por meio de um cabeçalho HTTP, mas também exige a existência de uma diretiva Limits configurada incorretamente no arquivo .htaccess . Esta publicação da Sophos oferece uma excelente visão geral dos sórdidos detalhes técnicos, caso você tenha interesse. Resumindo: se houver essa configuração incorreta, um invasor poderá explorar uma vulnerabilidade no Apache por meio do cabeçalho do método HTTP e, ao que parece, forçar o servidor a “vazar” dados que pertencem a outra pessoa.

Bem, eu disse tudo isso para poder dizer o seguinte: a segurança de aplicativos é composta por várias camadas. Essas camadas incluem as plataformas (e, portanto, os protocolos) das quais os aplicativos dependem. Como o HTTP.

Precisamos proteger melhor o HTTP contra abusos que comprometam a segurança. Não importa se o resultado é um vazamento de dados, um ataque de negação de serviço (DoS) ou um acesso remoto. Todos eles têm consequências negativas. Precisamos reconhecer melhor que o HTTP é uma superfície de ataque cada vez mais visada. Por ser baseado em texto, toda a interação entre um cliente e o serviço HTTP deve ser classificada como entrada do usuário.

Isso, por sua vez, deve incentivar uma estratégia de segurança que inclua a sanitização desses dados de entrada. Sim, isso significa aplicar o protocolo e filtrar os dados em uma etapa anterior (antes que cheguem a um servidor HTTP potencialmente vulnerável).

Isso significa que um firewall de aplicação web ou proxy programável deve ficar à frente de qualquer serviço HTTP acessível publicamente e filtrar ativamente as solicitações HTTP recebidas.

O motivo disso está relacionado à forma como as plataformas web processam os cabeçalhos HTTP, ou seja, antes mesmo de a solicitação ser vista por um desenvolvedor. Portanto, não podemos necessariamente responsabilizar os desenvolvedores e atribuir vulnerabilidades no nível da plataforma a práticas de programação inseguras.

Aplicar patches é, obviamente, a solução definitiva. Desde que você (1) tome conhecimento da vulnerabilidade no dia zero, (2) um patch seja disponibilizado no dia zero e (3) se sinta à vontade para implantar em sistemas de produção um patch que talvez não tenha sido testado.

É preciso aplicar as correções, não me entenda mal, mas há um intervalo entre a divulgação, a descoberta, a disponibilização e a aplicação. É nesse intervalo que reside o risco: o de que uma vulnerabilidade muito fácil de explorar seja usada contra você.

A penúltima solução é garantir que haja um sistema (uma plataforma) no qual você possa implementar imediatamente soluções de correção, como scripts ou varredura baseada em assinaturas, para impedir a exploração enquanto se prepara para aplicar a correção.

A filtragem de dados de entrada e a aplicação da conformidade com os protocolos devem ser partes integrantes de qualquer política de segurança corporativa.

O HTTP apresenta riscos cada vez maiores, mas eles podem ser gerenciados se você tiver em mente que a segurança de aplicações é composta por várias camadas e implementar proteções em cada uma delas.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie