BT
x A sua opinião é importante! Por favor preencha a pesquisa do InfoQ sobre os seus hábitos de leitura!

Vulnerabilidades de segurança com HTML5 e WebSockets?

por Mark Little , traduzido por André Campanini em 19 Abr 2012 |

Apesar de ainda não ser um padrão oficial, o HTML5 tem crescido rapidamente em termos de adoção e influência nos últimos anos. Seja a Web, mobile, ou mesmo SOA, todos parecem ter uma estratégia para integração com o HTML5. Entretanto, o HTML5 é mais do que apenas uma atualização para a linguagem de marcação original, pois abrange outros aspectos, tais como JavaScript e WebSockets. Muito se tem falado sobre WebSockets ultimamente, incluindo introduções à tecnologia e se ela tem ou não qualquer impacto sobre REST. No entanto, Lori MacVittie argumentou recentemente que WebSockets pode resultar em uma Web menos segura ao passo que as pessoas abrem mão da segurança por desempenho. Como ela aponta, citando um relatório de 2011, muitas pessoas já estão acostumadas a fazer dessa maneira, e também uma pesquisa constatou que ...

... 91% dos entrevistados estão privilegiando desempenho em detrimento da segurança e desempenho, e 81% estão na verdade desativando recursos de segurança.

Mas o que isto tem a ver com WebSockets? De acordo com Lori MacVittie, porque WebSockets remove cabeçalhos HTTP, entre outras coisas, abrem-se vulnerabilidades pois são removidas informações utilizadas pelos verificadores de vírus e de malware atuais:

Você sabe, coisas como Content-Type, o cabeçalho diz a outra ponta o tipo de conteúdo sendo transferido, por exemplo text/html e video/avi. Uma das coisas em que anti-vírus e soluções de verificação de malware são muito bons é a detecção de anomalias em tipos específicos de conteúdo. O problema é que, sem um tipo MIME, a capacidade de se identificar corretamente um determinado objeto fica um pouco duvidosa.

É claro que confiar em cabeçalhos HTTP não é garantia contra conteúdo malicioso, mas como Lori MacVittie menciona:

De modo geral, a aplicação que serve os dados não mente sobre o tipo desses dados, e são raras as vulnerabilidades que tentam manipular esta informação. Afinal de contas, alguém mal-intencionado, que queira entregar um payload malicioso, deve fazer isso através de um meio específico, porque esse é o fundamento sobre o qual muitas explorações de falhas (exploits) são baseadas - a execução de uma operação específica sobre um conteúdo específico. Isso significa que esse alguém realmente precisa que a outra ponta acredite que o conteúdo é do tipo que ela pensa que é.

E Lori MacVittie prossegue afirmando que o aspecto de extensibilidade de WebSockets (um subprotocolo de extensão presente na especificação), que possibilita a definição de protocolos e até formatos binários adicionais, apresenta outras questões que impedem firewalls de contornar o problema:

[...] Não há nenhuma maneira de saber com segurança o que está sendo passado através de um WebSocket a menos que você "conheça" a linguagem utilizada, a qual você pode ou não ter acesso. O resultado de toda essa confusão é que softwares de segurança são projetados para verificar se há assinaturas específicas ou anomalias dentro de tipos específicos de conteúdo. Eles perdem a capacidade de extrair os objetos trafegandos através de um WebSocket porque não há indicação de onde cada um começa ou termina, ou mesmo quais os seus tipos. A perda de cabeçalhos HTTP que indicam não somente o tipo, mas também o comprimento, é problemática para qualquer software - ou hardware, neste caso - que necessita extrair e processar os dados.

Houve relatos de falhas de segurança com o protocolo e implementações WebSocket, assim como houve com os outros protocolos da Web através dos anos. E, claro, segurança em sistemas distribuídos antecede HTML por várias décadas, especialmente com relação a protocolos binários. É possível proteger os sistemas binários, mas o ponto de Lori MacVittie parece ser que, enquanto todos parecem estar caminhando rapidamente para uma Web de melhor desempenho, não se deve ignorar o fato de que a grande maioria da infra-estrutura da Web é baseada em HTTP, e removê-lo ou substituí-lo não deve ser decidido de forma impensada, pois certamente algumas coisas vão deixar de funcionar, ou até pior. Já que parece inevitável adotar WebSockets, não seria hora de voltar atrás e considerar como um mundo baseado nele deveria se parecer, pelo menos no que diz respeito à segurança?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT