O HTML5 e os riscos de implementação do armazenamento local by Joao Silva

O HTML5 e os riscos de implementação do armazenamento local João Silva ISCTE Lisboa, Portugal joaosantacruz@gmail.com

Resumo. As aplicações web estão a tornar-se incrivelmente mais ricas com a utilização de HTML5. Os browsers, já não são apenas renderizadores de páginas de internet, gerindo também aplicações complexas e exigentes. O armazenamento local de dados é um dos aspectos introduzidos pelo mais recente standard do HTML5, sendo também aquele que mais preocupações gerou. Este artigo pretende identificar e detalhar os problemas de segurança relacionados com o armazenamento local de informação, recomendando um conjunto de boas práticas que minimizam a os riscos envolvidos na sua utilização. Keywords: HTML5, Armazenamento Local, Persistência de Dados , Segurança Web.

1 Introdução Lançado no Outono de 1994, a versão beta do Mosaic Netscape introduziu pela primeira vez o conceito de armazenamento local numa página a correr num browser web. Estes pequenos pares nome-valor, de tamanho reduzido e limitado a 4KB, foram apelidados de cookies. Até essa altura, cada “visita” a um website era entendida pelo servidor como a primeira, qualquer transacção comercial teria de ser realizada numa só visita [1]. Com o acesso a esta tecnologia, o browser podia guardar informação ao longo da navegação, e inclusivamente, mantê-la entre várias visitas. Os websites proporcionavam ao utilizador experiências muito mais completas, contribuindo para a

transformação de um mundo de conteúdos estáticos, num fenómeno que mais tarde conhecemos pelo nome “Web 2.0”. Apesar da velocidade das ligações atenuar de alguma forma, a necessidade de utilizar alojamento do lado do cliente, existem áreas de aplicação onde a sua utilização é essencial, como exemplo, o desenvolvimento de software para dispositivos móveis [3].

Dispositivos móveis Os dispositivos móveis são cada vez mais o frontend da internet [5], no entanto, limitações de processamento e velocidade na transferência de dados, juntamente com o custo elevado das comunicações, aumentam a pressão no sentido da criação de aplicações e versões mobile de websites que recorram a persistência de dados. Se avançarmos um pouco e analisarmos o passado recente da utilização de persistência de dados em páginas web, comprovamos a existência diversos sistemas que permitiram guardar informação do lado do cliente, mesmo depois de fecharmos o browser ou o separador (e.g. Google Gears, Flash, Silverlight e as Applets JAVA). Toda esta tecnologia deverá ser brevemente ultrapassada pelo standard introduzido pelo HTML5 [2].

2 Armazenamento local com HTML5 O documento que especifica o stardard HTML5 descreve dois mecanismos relacionados, similares aos “Cookies HTTP”, para armazenar informação do lado do cliente: Session Storage e Local Storage. Neste artigo , vamos ainda considerar o Database Storage, como forma de armazenamento local do lado do cliente.

2.1 Session storage As grandes diferenças entre os “cookies” e o armazenamento local apresentado pelo HTML5, estão na limitação de espaço disponível, que passa agora para valores na ordem dos 4MB (dependendo da implementação do browser), e na lógica de implementação da comunicação cliente-servidor onde, ao contrário dos “cookies”, a informação armazenada não é obrigatoriamente (depende da implementação do programador) enviada em cada pedido efectuado ao servidor, obtendo desta forma, um “payload” mínimo por cada transacção. A informação guardada com sessionStorage estará disponível apenas na janela que a gerou, e será perdida quando a janela do browser fechar.

// defining the session variable sessionStorage.setItem('userName', 'joao'); // accessing it alert("Hello" + sessionStorage.userName); // finally, unsing it sessionStorage.removeItem('userName');

Ver mais: http://joaosantacruz.com/html5/localstorage/sessionStorage/

2.2 Local storage Muito idêntico ao SessionStorage explicado anteriormente, o LocalStorage apenas difere na persistência e no âmbito de actuação (scope). A informação guardada permanece guardada no browser, mesmo depois de fecharmos a janela do browser. Com LocalStorage os dados estão estão acessíveis em todas as janelas do browser, enquanto que no SessionStorage o acesso está limitado à janela que os guardou.

// defining the session variable localStorage.setItem('userName', 'joao'); // accessing it alert("Hello " + localStorage.userName); // finally unset it localStorage.removeItem('userName');

Ver mais: http://joaosantacruz.com/html5/localstorage/localStorage/

2.3 Database StorageProgram Code Até agora abordámos várias formas de armazenamento local que estava limitado a pares chave-valor, mas quanto temos grandes quantidades de informação, as base de dados podem ser a solução. O HTML5 implementa uma base de dados do lado do cliente que pode ser utilizada para guardar e aceder a informação através de Javascript. Utilizando bases de dados SQLite, este tipo de armazenamento ainda não é suportado por todos os browsers, mas está até ao momento a ter uma grande aceitação.

var db = openDatabase("moss_db", "1.0"); database.executeSql("SELECT * FROM class",

function(result1) {

// do something with data database.executeSql("DROP TABLE class", function(result2) { // do some more cleanup or blah alert("My second database query finished executing!"); }); });

Ver mais: http://joaosantacruz.com/html5/localstorage/session/database/

O armazenamento local em base de dados levanta desde logo algumas questões, grande parte delas estão relacionadas com a segurança da informação: Será seguro armazenar informação do lado do cliente? Como fazê-lo da forma mais segura?

3 Riscos de implementação De todas as funcionalidades do HTML5, o armazenamento local é aquela que tem mais impactos na segurança da informação. Pelos níveis de adesão à tecnologia, é expectável que se venha a assistir a uma utilização cada vez maior do armazenamento local. Quanto maior for a quantidade de dados guardados do lado do cliente, maior será a tentação de atacar os sistemas que os guardam. Os dois principais riscos

envolvidos na implementação de sistemas de armazenamento local são os riscos de leitura e os riscos de escrita.

3.1 Risco de Escrita Permitir que o “website atacante” consiga escrever dados no “website vítima” pode resultar em fraude de informação (information spoofing). Exemplo: “O Francisco trabalha na Building&Company, tem a seu cargo a tarefa de realizar o orçamento para um projecto importante na área da Grande Lisboa. Utilizando a fragilidade de um sistema de web-mail, uma empresa concorrente consegue introduzir uma mensagem na caixa de entrada do Francisco com o intuito de o levar a desistir do projecto.”

3.2 Riscos de Escrita Permitir que o “website atacante” consiga escrever dados no “website vítima” pode resultar em fraude de informação (information spoofing). Exemplo: “O Francisco trabalha na Building&Company, tem a seu cargo a tarefa de realizar o orçamento para um projecto importante na área da Grande Lisboa. Utilizando a fragilidade de um sistema de web-mail, uma empresa concorrente consegue introduzir uma mensagem na caixa de entrada do Francisco com o intuito de o levar a desistir do projecto.”

4 Exemplos de ataque Considerando a especificação do Standard do HTML5, no que diz respeito à segurança do armazenamento local, estão definidas normas que visam a garantia da privacidade e segurança dos dados armazenados, uma das quais indica que só o website com o domínio que criou o armazenamento local, deverá aceder aos dados 6

nele contidos. Apesar da aparente sensação de conforto, a experiência adquirida com as redes informáticas, traz-nos de volta a realidade que encontrámos na web. Sabemos que existem “ataques” que permitem contornar e quebrar os princípios básicos de segurança definidos pela especificação do HTML5.

4.1 DNS spoofing Com a fraude de DNS, não é possível garantir que um host que diz pertencer a certo domínio, faz realmente parte desse domínio. Para evitar esta situação, as páginas podem usar TLS, sistema que certifica que uma página pertence a determinado domínio e consequentemente permite o acesso à informação alojada.

4.2 Cross-directory Este cenário ocorre quando dois websites partilham um domínio, sendo diferenciados por um sub-domínio ou sub-pasta (e.g. vitima.no.sapo.pt e atacante.no.sapo.pt). Uma vez que não existe uma funcionalidade que distinga os dois websites por sub-pasta, o objecto de armazenamento local vai ser partilhado por ambos, tornando o acesso ou sobreposição da informação numa tarefa bastante simples. A utilização de armazenamento local em sistemas de domínio partilhado, é por esta razão, pouco aconselhada.

4.3 Cross-site scripting (XSS) O XSS é uma vulnerabilidade muito comum em websites e que permite aos atacantes, injectar código que irá correr directamente nos browsers de outros utilizadores que estejam a consultar o website infectado. Este tipo de ataque pode ser utilizado, entre outras coisas, para ultrapassar um sistema de autenticação ou para obter uma informação guardada localmente. Os efeitos deste ataques dependem do tipo de informação em questão e de possíveis implementações de “contra-ataque”.

5 Boas práticas de implementação

5.1 Não guardar dados sensíveis Dados públicos que em situação normal não requeiram autenticação para serem visualizados, podem ser guardados do lado do cliente. Informação do tipo: passwords, pin's do do cartão de crédito e códigos pessoais nunca deverá ser armazenada localmente. Não devemos guardar informação sensível em armazenamento local. Exemplo: A agência de viagens “AlgarveTour”, no seu website, apresenta diversas vezes o mesmo produto, uma vez que existem muitas datas para o mesmo destino. Para reduzir o tráfego, poupar no processamento de servidor e aumentar a velocidade de carregamento das páginas, poderia neste caso ser utilizado armazenamento local, guardando itens já visualizados para futuros pedidos. Em casos de extrema necessidade, alguns dados sensíveis terão de ser guardados localmente. Para estes casos existe um conjunto de boas práticas que pretendem minimizar o risco de ataque.

5.2 Informar o utilizador Muito resumidamente, podemos guardar informação quando depois de devidamente alertado e informado acerca do tipo de dados a armazenar, o utilizador o permitir explicitamente. Só após esta confirmação o sistema guardará informação no armazenamento local. Se o utilizador mudar de computador, terá de ser alertado novamente, sendo repetido o processo descrito anteriormente. No caso de existirem várias instâncias armazenadas(em vários computadores), as aplicações deverão também possuir métodos de identificação de instâncias, possivelmente guardadas no lado do servidor, para que sejam detectadas quaisquer tentativas de fraude.

5.3 Não confiar nos dados Informação armazenada localmente não é de confiança pelo que deverão ser criados mecanismos de detecção de intrusão.

5.4 Utilização de Secure Sockets Layer (SSL) Deverão ser utilizadas ligações seguras como é o caso do “https”. Pelo que vimos anteriormente, não será possível aceder ao armazenamento local de um dominio “http” se a informação foi guardada em “https”. Esta medida evita o acesso aos dados por via de ataques de DNS spoofing.

5.5 Evitar difusão de nomes Para que um atacante possa consultar ou escrever determinado valor no armazenamento local, terá necessariamente de saber o nome das chaves do par chavevalor, uma vez que com esta tecnologia não é possível enumerar todos os pares existentes. Idealmente, estas chaves tem um nome diferente de utilizador para utilizador e devem garantir alguma segurança pela sua constituição, ou seja, devem ser difíceis de “adivinhar”.

5.5.1 Nomes únicos Os nomes das variáveis ou bases de dados, podem ser criados através de algoritmos de geração aleatória e guardados no servidor, sendo adicionados ao script que corre do lado do cliente depois da autenticação. Desta forma um ataque por Cross-site Scripting or DNS Spoofing, não sortirá quaisquer efeitos, uma vez que está aceder a algo que não conhece. NOTA: Apesar de eficaz, esta solução anterior compromete o acesso “offline” à aplicação uma vez que os dados armazenados do lado do servidor são essenciais ao seu funcionamento.

5.5.2 Password offline Guardar nomes de variáveis ou bases de dados do lado do cliente é, como já vimos, bastante inseguro uma vez que os mesmos podem ser acedidos através de scripts maliciosos. Uma solução passará por criar uma password offline, que será utilizada como prefixo de todas as varáveis da aplicação. Sempre que alterado o valor desta password, o sistema terá de actualizar automaticamente os respectivos dados do lado do cliente.

5.5.3 Password centralizada no browser Os browsers poderão implementar sistemas de password centralizada que permitem decifrar os nomes das variáveis e/ou bases de dados.

5.6 Codificação de dados De forma a evitar o Cross-Site Scripting toda a informação armazenada do lado do cliente, deverá ser filtrada e codificada antes de ser armazenada e depois de ser consultada.

5.7 Prevenir SQL injections Podemos prevenir SQL Injections do lado do cliente, utilizando “prepeted statments” em todas as interacções com a base de dados. Este método de consulta a base de dados, está muito facilitado no HTML5, pelo que a sua utilização é muito simples.

5.8 Prevenir infecções por XSS Este é provavelmente o ponto mais crítico ao nível da segurança de aplicações web. É também um dos pontos fundamentais a considerar, se queremos proteger informação que está armazenada localmente do lado do cliente.

Por muito que se discuta a problemática do XSS, e se descubram formas de o evitar, a verdade é que muitos web-developers ainda não têm consciência que este é um fenómeno bastante comum.

Fig. 1. 2010 Web Application Attacks, A figura apresenta a distribuição categorizada, dos ataques realizados no ano de 2010. Mais informação pode ser consultada em tempo real em: http://chaptersinwebsecurity.blogspot.com/

Todos os dados que são inseridos por um utilizador, podem potencialmente ser uma fonte de XSS malicioso, mesmo que não seja uma situação óbvia de entrada para código HTML. NOTA: Uma aplicação não pode aceder a código introduzido através de um dos seus pontos de entrada, sem verificar, filtrar e codificar essa informação.

6 Conclusão O standard HTML5 representa de facto uma tecnologia fantástica, no entanto algumas das suas novas funcionalidades, podem introduzir, se mal implementadas, graves falhas de segurança. Relativamente ao armazenamento local, é expectável que apenas a aplicação que armazenou a informação, venha mais tarde a ter acesso à mesma. Mas quando um website apresenta vulnerabilidades XSS (Cross-site Scripting), um atacante poderá ter acesso à informação guardada. Sendo que as vulnerabilidades XSS muito comuns em websites e tendo sido verificada uma forte adesão a estas funcionalidades por parte dos programadores, não será de difícil de prever que existem actualmente muitos dados em risco. Existem alguns métodos, que resultam de um conjunto de boas práticas de desenvolvimento, que podem minimizar a exposição de uma aplicação. Assim sendo, ,a utilização consciente desta tecnologia é fundamental num processo de desenvolvimento que deve assumir o compromisso de garantir, na medida do possível, a segurança dos dados do utilizador.

7 Referências [1] Schwartz, J. 2001: Giving the Web a Memory Costs Its Users Privacy. New York Times. [2] HTML5 - A vocabulary and associated APIs for HTML and XHTML http://dev.w3.org/html5/webstorage/ [3] Stark, J. 2010. Building Android Apps with-HTML CSS and JavaScript. O’Reilly [4] Attack and Defense Labs 2011. HTML5 - Security Quick Reference Guide with Demos http://www.andlabs.org/html5.html [5] Kotz, D. and Gray, R. 1999. Mobile Agents and the Future of the Internet. Department of Computer Science / Thayer School of Engineering, Dartmouth College [6] Hickson, I., Google, Inc. 2011, W3C Specification - Web Storage

http://dev.w3.org/html5/webstorage/ [7] Hickson, I., Google, Inc. 2011, W3C - Specification - Web Sql Database http://dev.w3.org/html5/webdatabase/ [8] Google, Inc. 2011, html5security, HTML5 Security Cheatsheet, http://code.google.com/p/html5security/wiki/WebSQLDatabaseSecurity