Visão geral de segurança do HTML5

O HTML5 é um padrão atual e novos recursos estão sendo adicionados enquanto você lê este artigo. Os navegadores terão cada vez mais um melhor suporte a este padrão. No entanto, esses novos recursos também trazem novas oportunidades aos atacantes para assumir o controle e aumentar complexidade de segurança web.

Neste artigo vamos mostrar apenas algumas das novas funcionalidades do HTML 5 que abrem novos horizontes para exploração.

Iremos examinar alguns novos vetores de ataque causados por novos atributos e elementos e os problemas que eles causam no uso da técnica de criação de listas negras. Vamos mostrar como as adições à API de histórico podem se transformar em um incômodo para o usuário e como um arquivo SVG pode se tornar malicioso. Mostraremos como os dados do usuário, incluindo cookies, endereço de IP, agente de usuário e componentes de armazenamento da web HTML5 podem chegar nas mãos de um usuário malicioso com a edição de um único script. Vamos construir um script que armazena todos os dados em um arquivo de texto e requer apenas que o invasor adicione esse script em uma página de terceiros. Finalmente, iremos apresentar como os navegadores podem prevenir algumas formas de XSS e introduzir CORS.

Novos vetores de ataque

Existem três formas de lidar com a entrada do usuário – codificar a saída (por exemplo, converter os caracteres especiais no HTML para entidades), filtrá-la através de whitelists (permitir apenas determinados valores) ou filtrá-la através de blacklists (desautorizar determinados valores, por exemplo: não permitir que os usuários adicionem ou usem um * = “”). No mundo do HTML, o último é incrivelmente ineficiente, pois HTML é um padrão atual e de novos elementos, atributos e ouvintes de eventos surgem o tempo todo. Isso é evidenciado pelo HTML5.

Se você criou uma blacklist, o HTML5 criou novos atributos como onforminput, onde seus filtros podem não se encaixar. Existem atributos, que podem ser estrategicamente utilizados por atacantes sem sequer começar em *. Por exemplo, se você estiver exibindo a entrada do usuário (uma tag de uma lista de tags permitidas filtrou os atributos para certas pessoas permitidas) dentro de um formulário, em seguida, os invasores podem usar o novo atributo para redirecionar a submissão do formulário para um servidor arbitrário. Tais atributos podem ser aplicados a elementos como o e e permitir que um invasor em potencial não só redirecione o envio do formulário, mas mude o método de solicitação (através do atributo formmethod), impedindo que o formulário de validação (usando o atributo formnovalidate) altere o tipo de codificação (através do atributo formenctype) e outros vetores recém formulados.

No passado, se você quisesse acionar automaticamente um determinado trecho de JavaScript, você teria que usar onmouseover e torcer para que a vítima colocasse o seu mouse sobre o elemento. Com HTML5, o JavaScript injetado pode ser automaticamente executado por cada usuário que visita essa página, adicionando um manipulador de eventos onfocus acompanhado pelo atributo autofocus.

Por exemplo, simplesmente adicionando a linha abaixo cada usuário visitante será redirecionado para um site arbitrário antes mesmo de a página carregar.

Print1

API de histórico do navegador

As adições da API de histórico do navegador, ou seja, pushState, replaceState e popstate tem fins legítimos – elas aliviam sites AJAX em funcionamento, permitindo-lhes o registro de determinadas ações como páginas no histórico do navegador e permitindo que os desenvolvedores alterem a URL no navegador em conformidade para refletir a ação do usuário facilitando a navegação e a partilha de bits dos sites AJAX com os outros.

No entanto, os sites podem impedi-lo de voltar para outro site, forçando um determinado site várias vezes através de loopings e interações. Isso não exige muito tempo, esforço e código para fazer:

Print 2

O trecho acima é suficiente para fazer você clicar em voltar 10 vezes apenas para deixar o auto-denominado bestwebpage.html. Ele poderia facilmente ter sido de 100 ou 1.000 vezes.

Páginas maliciosas também podem preencher o histórico do navegador da vítima com nomes de página de aparência suspeita para diversos fins – como blackmail. Eles podem até mesmo enganar usuários desavisados pensando que estão em um site diferente, substituindo o estado do histórico:

Print3

A chamada replaceState acima resultaria na seguinte URL mostrada para o usuário, que pode ser confuso para os usuários desavisados:

Print4

SVG

O HTML5 permite que gráficos SVG sejam inseridos em documentos e eles poderiam ser criados em linha dentro do documento usando a tag . Se nós estamos adicionando o gráfico SVG para o documento usando a tag , então um JavaScript malicioso dentro do arquivo SVG não seria executado a menos que o usuário salve o arquivo / imagem e veja como um standalone no seu navegador.

Print5

Você pode ver que dentro da tag svg podemos colocar uma tag de script e adicionar um JavaScript arbitrário que seria executado junto com os gráficos renderizados cada vez que o usuário visualiza a página com esse gráfico.

Agora, o usuário pode realmente gostar do coração e baixá-lo para visualização posterior.

Print6

Depois que o usuário tiver baixado e aberto ele ficará surpreso.

Imagine que entre os elementos de criação do gráfico temos um script que verifica se o usuário está executando o Google Chrome e se ele é – ele informa ao usuário que o navegador Google Chrome detecta que o usuário está tentando acessar uma imagem inadequada para menores e solicita que o usuário forneça as credenciais com as quais ele efetua login no Google Chrome (sua conta do Google). Depois de fornecer os dados, a SVG redireciona o usuário para um site malicioso e envia as suas credenciais. O exemplo a seguir é uma simplificação de um cenário do mundo real de exemplo:

Print7

A única coisa de atenção especial no trecho de código acima é o fato de que temos utilizado o & cada vez que queria usar & em nosso código JavaScript devido à forma como funciona o SVG.

Web Storage

As novas APIs Web Storage HTML5 permitem que os desenvolvedores web armazenem cerca de 5 megabytes de dados (em comparação com apenas 4 kilobytes permitidos em cookies) na máquina do usuário e facilita aplicações offline. Os dados armazenados não são enviados a cada solicitação HTTP para que ele não cause sobrecarga no requerimento do usuário. Por exemplo, StackEdit permite escrever artigos ou outros pedaços de texto no Markdown totalmente offline. Todos os seus artigos são salvos no armazenamento local até que você remova ou até que o usuário exclua manualmente. Session Storage mantém os dados disponíveis até que o usuário feche seu navegador. Agora imagine aplicativos web que salvam seus e-mails, histórico de compras / vendas, carteiras e-mails localmente e pense se isso é seguro. Armazenamento Web torna-se um ativo cada vez mais importante para examinar os atacantes. Vamos considerar um caso prático. Se um site já é vulnerável a XSS, em seguida, o atacante pode obter acesso não só aos cookies (a menos que eles sejam definidos como HTTPOnly) mas também aos armazenamentos locais e de sessão. Assim, colocar um simples identificador de sessão do usuário na Web de armazenamento não é uma boa idéia, pois não há nenhuma bandeira HTTPOnly para diminuir os efeitos de uma falha de segurança em potencial.

Vamos considerar um script vulnerável do lado do servidor como este abaixo:

Print8

O aplicativo exemplo leva um parâmetro de consulta chamado “q” e procura por uma partida em um conjunto de resultados possíveis. Se for encontrado, ele mostra todos os resultados relevantes em um link.

Este aplicativo exemplo usa tanto localStorage e sessionStorage. Ele usa localStorage para armazenar cada consulta de pesquisa anterior do usuário e o número de vezes que a consulta foi repetida. Session Storage é usada para armazenar a última consulta de pesquisa feita.

Na realidade, é possível que os atacantes se apossem de cookies e valores do usuário armazenados na Web de armazenamento com uma única solicitação mal-intencionada de explorar uma vulnerabilidade XSS ou como várias formas de injeções de código.

O script recupera o endereço do usuário público IP, seus cookies, valores armazenados no armazenamento local, sessão e seu agente de usuário e insere eles em um arquivo de texto no qual os usuários separados e peças separadas de dados são separadas por linha. Pelo que vimos aqui – podemos possivelmente sequestrar a sessão do usuário a partir do cookie PHPSESSID. Podemos, eventualmente, aprender sobre as capacidades e vulnerabilidades do navegador do usuário (navegadores mais recentes tentam apresentar-se como navegadores diferentes ou múltiplos para evitarem de ser rastreados), e usar as informações armazenadas na Web de armazenamento de qualquer maneira que nós gostamos – a informação poderia conter e-mails sensíveis, artigos inéditos de um famoso blogueiro escrito em StackEdit ou outros dados úteis.

Para executar nosso script tudo o que temos a fazer é explorar a fraqueza de um site para adicionar um script arbitrário. Por exemplo, se o site é vulnerável a XSS poderíamos enviar a URLs semelhante abaixo:

http://www.vulnerablesite.example.com/?q=

Em seguida, todos os dados do usuário estarão disponíveis no collected-data.txt no mesmo diretório onde o script JS está.

Alguns navegadores implementaram auditores XSS, que impedem algumas formas de XSS e outras vulnerabilidades comuns.

No entanto, isso não é verdade para todos os navegadores, especialmente os mais velhos. Internet Explorer 11, o suspeito de costume, permitiu o XSS a tomar lugar e os dados de um site que foi salvo com sucesso no arquivo de texto localizada em um servidor remoto (outro site).

O HTML5 permite que os desenvolvedores garantam que os navegadores compatíveis protejam seus usuários contra ataques de XSS usando o cabeçalho X-XSS-Protection. Para ativá-lo e bloquear tais casos use o seguinte cabeçalho: X-XSS-Protection: 1; mode = block.

CORS (Crpss-Origin Resource Sharing)

Essa é outra camada de proteção. Portanto, nosso script do extrator de dados teria que permitir a qualquer utilizador solicitá-lo por meio de AJAX, para isso, permitiremos todas as origens.

O cabeçalho de Origin não elimina a possibilidade de CSRFs, mesmo que você os tokenizem e ainda é possível alterar o valor do cabeçalho de Origem, em determinadas circunstâncias (por exemplo, entidades não-navegador).

Conclusão

O HTML5 trouxe muito mais recursos do que o acima examinados e a maioria deles têm algumas implicações de segurança.

Acesse o conteúdo original (em inglês) no link.