Suas aplicações são seguras?

Conheça a Conviso!

HTML5 Security ou Insecurity?

Este artigo também disponível em versão pdf no Scribd.

Novos recursos exigem novos cuidados

Alguns ainda o mencionam com descaso, outros com euforia, mas o fato é: HTML5 está chegando, e com ele uma série de novos cuidados que deverão ser tomados no que se refere a segurança de aplicações web. Como uma série de novos recursos serão oferecidos, a semelhança com o atual HTML ficará apenas no conceito de tags. O World Wide Web Consortium (W3C) fornece um guia que mostra as diferenças entre o HTML4 e o HTML5 [1] que não são poucas.

O HTML5 implementa uma série de recursos que aumentam a importância e necessidade de cuidados com a proteção dos componentes, e todos que se aventurarem a desenvolver aplicações baseadas neste cenário deverão se atentar a uma forma, no mínimo, diferente de ver as coisas.

Client-Side Storage

O HTML5 oferece uma API para armazenamento local que possibilita a aplicação gravar no computador do usuário espantosos 5MB de dados.  Se antes era necessário utilizar um cookie para persistir uma sessão e este não podia ocupar mais do que 4kb para o armazenamento de strings, agora com os recursos de localStorage e sessionStorage, além da possibilidade de armazenamento de um volume bem maior, é possível ir muito além dos strings e armazenar, potencialmente, qualquer tipo de objeto.

Exemplo

Para exemplificar o funcionamento, veja abaixo uma ToDo List que armazena as informações em local storage:

<html>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″>
<title>ToDo List in HTML5</title>
</head>
<body>
<header>
<h1> My Simple To-Do List </h1>
</header>
<section>
<ul id=”edit” contenteditable=”true”>
<li></li>
</ul>
</section>
<em>Add some items, and refresh the page. It’ll remember what you typed.</em>

$(function() {
var edit = document.getElementById(‘edit’);
$(edit).blur(function() {
localStorage.setItem(‘todoData’, this.innerHTML);
});

// when the page loads
if ( localStorage.getItem(‘todoData’) ) {
edit.innerHTML = localStorage.getItem(‘todoData’);
}

// to reset
// localStorage.clear();

});

</body>
</html>

 

Cuidados

Os cuidados com este recursos são referentes ao armazenamento de dados sensíveis em client-side, pois mesmo com o volume de armazenamento em cookie sendo reduzido já é comum encontrar aplicações que armazenam dados sensíveis desta forma. Com este novo recurso a tendência é que os desenvolvedores o utilizem em excesso e consequentemente armazenem dados que não deveriam estar disponíveis em client-side.
Outro fato interessante é que agora iremos começar a nos deparar com ataques de SQL Injection [2] que buscam interagir com dados armazenados no storage local do computador do usuário. Isso mesmo, estamos falando de SQL Injection Client-Side, diferente do tradicional no qual você interage com o banco de dados que está em server-side. E também pode ser explorado o XSS (Cross Site Scripting) Armazenado [3], onde o usuário mal intencionado consegue armazenar um código javascript que é executado quando a aplicação carrega os dados armazenados na local storage.

Same-Origin Policy

O HTML5 possibilita definir se a aplicação irá ou não se comunicar com aplicações em outros domínios. Por padrão, os web browsers forçam o controle de origem de requisições HTTP, então uma aplicação no domínio conviso.com.br não pode fazer requisições em javascript no domínio conviso.com. Se precisávamos usar hacks em AJAX, CSS e Flash para fazer requisições entre domínios diferentes, com o HTML5 podemos definir nas tags com quais domínios a aplicação tem uma relação de confiança, um recurso similar ao que pode ser implementado com Flash usando o arquivo crossdomain.xml.

Exemplo

Um exemplo de definição insegura de Same-Origin Policy é:

<?php
header(‘Access-Control-Allow-Origin: *’);
?>

Esta definição permite que a aplicação interaja com qualquer domínio, uma vez que ocorre a quebra do controle de origem do browser.

Cuidados

Neste aspecto, os desenvolvedores devem tomar cuidado para não quebrar um recurso nativo: o controle de origem das requisições. Se for necessário a comunicação entre aplicações em domínios distintos é fundamental especificar claramente qual é este domínio, recurso que pode ser compartilhado, e não podemos simplesmente definir a comunicação entre domínios distintos para qualquer domínio.

Este recurso já está sendo usado para explorar falhas e também como base para ferramentas que possibilitam o proxy através de XSS. O pesquisador Matt, do m-austin.com, já demonstrou uma falha de XSS que pode ser explorada no Facebook devido a quebra de Same-Origin Policy [4] e o pessoal do Andlabs apresentou o que eles chamam de nova abordagem para shell-reverso usando também os recursos da Same-Origin Policy [5].

Cross-Document Messaging

É um recurso bem semelhante ao Same-Origin Policy , onde existe a possibilidade de trocar mensagens entre uma aplicação e outra em domínios distintos.

Exemplo

Aqui vamos exemplificar uma mensagem sendo enviada de um domínio para o outro.

Código de envio de mensagem do domínio a:

var o = document.getElementsByTagName(‘iframe’)[0];
o.contentWindow.postMessage(‘Hello world’, ‘http://b.example.org/’);

Código rodando no domínio b para receber a mensagem do domínio a:
window.addEventListener(‘message’, receiver, false);
function receiver(e) {
if (e.origin == ‘http://example.com’) {
if (e.data == ‘Hello world’) {
e.source.postMessage(‘Hello’, e.origin);
} else {
alert(e.data);
}
}
}

 

Cuidados

Os cuidados aqui se referem a garantia de origem. É necessário garantir que as mensagens enviadas não estão sendo forjadas por um servidor malicioso e consequentemente ele possa enviar conteúdo malicioso a aplicação.
Outros pontos de destaque

Além destes recursos podemos ainda mencionar o grande aumento na superfície de ataques, afinal o HTML5 é muito mais poderoso e oferece recursos para desenvolver aplicações mais complexas. Mas o HTML5 não traz só recursos que devemos tomar cuidado, ele também traz recursos de segurança interessantes.

Um destes é o sandbox que implementa restrições de onde o processo é executado, ou fazendo uma analogia, é literalmente uma caixa de areia onde determinado processo só roda no seu cercado e não é interferido ou interfere em processos que rodam em paralelo. No HTML5 ele é interessante para controlar a injeção de iFrames maliciosas, este problema é a base para ataques bem elaborados como o já famoso Clickjacking. [6]

Referências

 

    1. “HTML5 differences from HTML4: W3C Working Draft 24 June 2010”, em http://www.w3.org/TR/2010/WD-html5-diff-20100624/.

 

    1. Um vídeo demonstrativo de ataques de injeção está disponível no canal da Conviso IT Security no YouTube em http://www.youtube.com/watch?v=Bi5eJ1WxJQk.

 

    1. Um vídeo demonstrativo de ataques de XSS está disponível no canal da Conviso IT Security no YouTube em http://www.youtube.com/user/ConvisoITSecurity#p/u/1/_YgZKDJlhjo

 

    1. “Hacking Facebook with HTML5” em http://m-austin.com/blog/?p=19.

 

    1. “Shell of the Future – Reverse Web Shell Handler for XSS Exploitation” em http://blog.andlabs.org/2010/07/shell-of-future-reverse-web-shell.

 

Sobre o Autor

Wagner Elias atua com Segurança da Informação desde 2004, tendo trabalhado como consultor, líder de equipes e gerente de consultoria. Tem ampla experiência na condução de projetos em IT Security com  soluções implementadas em empresas dos mais diversos segmentos. Possui as certificações CBCP, SANS GIAC GHTQ, ITIL e CobiT Foundations além de certificações de produtos de SIEM e WAF. É fundador e líder do capítulo brasileiro da OWASP, ocupou o cargo de diretor de conteúdo na gestão 2006-2008 e de eventos da gestão 2008-2010 do capítulo brasileiro da ISSA. É co-fundador e sócio da Conviso IT Security, onde atua como Gerente de Pesquisa e Desenvolvimento, responsável pela gestão de pesquisa e desenvolvimento de projetos de consultoria.

Originalmente postado no Blog da Conviso Application Security – Siga-nos no Twitter @conviso Google+

Tags

Deixe um comentário

topo
%d blogueiros gostam disto: