Amon Veiga Santana 1

Transcrição

1 SEGURANÇA EM JAVASCRIPT SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB UTILIZANDO JAVASCRIPT Amon Veiga Santana 1 1 Unifacs Salvador BA Brasil Resumo A produção de software é algo que demanda capacidade de unir usabilidade, aspecto visual agradável e funcionalidades interessantes. O javascript nasceu justamente para trazer e aprimorar estes recursos nas aplicações web. Entretanto um quarto quesito, a segurança, pode ser comprometido quando alguns padrões não são respeitados ou até mesmo por falhas existentes na linguagem ou no interpretador javascript do navegador. O poder que esta linguagem traz por a mesma rodar diretamente no lado do cliente, é justamente o principal motivo para as possibilidades de falha. Palavras chave: programação web, javascript, segurança, navegadores. 1. INTRODUÇÃO Os navegadores quando surgiram, eram capazes de manipular somente textos, tags de marcação e imagens de mapa de bits. Com a evolução da internet e a necessidade de tornar os sites mais dinâmicos e flexíveis, logo surgiu o conceito de 'helpers' (aplicativos adicionais) que posteriormente se transformaram nos atuais addons. Com a implementação de linguagens client side como javascript, vbscript e ActiveX, os navegadores passaram a receber código a serem interpretados, deixando de ser responsável somente pela apresentação do conteúdo, passando também a ser responsável por uma parcela da lógica da aplicação quando, por exemplo, o javascript é utilizado para dependendo das interações do usuário fazer o postback para outra página, ou mesmo alterando o conteúdo de um formulário dinamicamente. Dentre os três recursos acima, o javascript pode ser considerado o mais seguro, pois roda isoladamente no navegador, não tendo direito de acesso a recursos locais do

2 2 cliente, com exceção daqueles diretamente associados ao navegador, como por exemplo, cookies e histórico de navegação. Este isolamento torna-o mais adequado quando se trata de execução de funções que não precisam de recursos locais, mais não pode se utilizada para integração entre hardware e navegador, como é comum hoje em aplicações de realidade aumentada que necessita de acesso a uma webcam instalada no computador do cliente. 2. PROTEÇÃO DE CÓDIGO COM JAVASCRIPT O javascript pode ser usado com diversas finalidades. Entre elas podemos destacar a capacidade de ajudar a ocultar o código HTML, ou mesmo o javascript embutido no HTML. Esta técnica não é muito utilizada, devido a atualmente o núcleo da camada de negócio das aplicações estarem no lado do servidor, sendo desta forma não acessível pelo cliente. Entretanto, com o advento da web 2.0, recursos de interação, necessidade de atualizações parciais das páginas, o javascript junto com o XML está se tornando intensamente utilizado. Essa junção recebeu o rótulo de Ajax (Assyncronous Javascript And XML), e está cada dia mais presente em aplicações web que desejam implementar recursos parecidos com os encontrados em aplicações desktops. Como ilustração, podemos citar o Gmail, aplicativo de do Google, que inova cada dia neste aspecto, sendo um dos principais destaques na utilização intensa do mesmo. Essas aplicações que utilizam o javascript não somente como um acessório, mas sim como parte central da mesma, necessitam de alguma forma proteger o seu código fonte cliente site, tanto por motivos comerciais, como para evitar varredura do código com o objetivo de encontrar brechas por terceiros. Existem várias técnicas e formas de tentativa de ocultação de código, apesar de atualmente nenhuma delas ser totalmente inviolável. A forma mais básica seria bloqueando o acesso ao código fonte da página em questão através da interceptação do evento do botão direito do mouse. Esse recurso é muito primário, e facilmente contornado, sendo necessário códigos mais aprimorados para uma proteção mais consistente. Nesta linha, poderíamos descer um nível, e mudar nossa abordagem. Já que as técnicas de ocultação de código fonte não são tão eficazes, podemos criptografar o mesmo, ou impedir que este seja copiado ou impresso. Um evento muito eficaz para essa segunda situação seria manipular o cache do navegador, escutando as combinações de teclas que copiam e as que fazem impressão através do navegador. A tag <BODY onkeyup="return window.clipboarddata.cleardata();"> seria muito eficaz nesse sentido. Apesar de não impedir que o usuário copie o conteúdo, impede que o mesmo seja colado, já que ao copiar, é disparado o evento para limpar a área de transferência, o que pra efeitos práticos, tem o mesmo resultado de bloquear a cópia. É possível também bloquear a tecla printscreen, a opção arrastar, entre outras. A combinação de todos estes recursos tornaria bem difícil a reutilização do código, apesar de que em última instância, se de qualquer forma o usuário consegue ver o

3 3 código apesar de não conseguir copiar ou imprimi-lo, ele poderia simplesmente ler e digitar o mesmo em um simples bloco de notas. Neste caso, realmente concluímos que por mais que possamos dificultar, não podemos garantir o não acesso ao código. Surgiu então, outra abordagem para esta problemática. Já que o acesso ao código não é totalmente bloqueável, podemos tentar torná-lo ilegível, através de criptografia feita com o próprio javascript. É possível criptografar o código fonte, e somente descriptografá-lo na hora da execução. A decomposição da criptografia depende de uma chave que pode ser de até 56 caracteres. Abaixo temos um exemplo de uma função de criptografia: function Encripta(dados) var mensx=""; var l; var i; var j=0; var ch; ch = "assbdfbdpdpdpfpdaadpeoseslsqqecddldivvkadiedkdkllnm"; for (i=0;i<dados.length; i++) j++; l=(asc(dados.substr(i,1))+(asc(ch.substr(j,1)))); if (j==50) j=1; if (l>255) l-=256; mensx+=(chr(l)); document.getelementbyid("1").value=mensx; Fonte: Apesar de ser muito efetiva, podemos destacar que a criptografia torna a aplicação muito mais lenta (processamento), assim como mais pesada (consome mais banda), fazendo com que se pense duas vezes sobre os reais benefícios. Além disso, já que o javascript é client side, para descriptografar os dados é necessário que a chave seja armazenada na aplicação web. Ainda assim, só é possível criptografar uma parte da aplicação, especialmente algumas funções de lógica, mas não aquelas associadas a eventos HTML. Todos esses recursos de proteção abordados são úteis como dificultadores, mas não funcionam como garantia para uma efetiva proteção do código fonte. Se por um lado isso pode ser negativo do ponto de vista dos desenvolvedores, por outra ótica, isto pode ser considerado um aspecto de segurança para os usuários, já que na prática, não dá para encapsular funções javascript, tornando a aplicação mais transparente e fazendo com que o usuário possa saber, se quiser, o que exatamente o código faz. Toda essa incapacidade de encapsulamento está justamente associada ao fato de o javascript rodar somente no navegador, sendo possível fazermos uma comparação com a sandbox que ocorre no Java.

4 4 3. SEGURANÇA DE DADOS COM JAVASCRIPT A técnica de criptografia de dados citada no tópico anterior também pode ser usada para a transmissão/recebimento de informações fornecidas pelo usuário através de um formulário. Da mesma forma ela ajuda, mas não é totalmente eficaz. Entretanto, do ponto de vista de um sniffer, esta técnica seria um dificultador considerável. Os dados postados por um usuário e/ou reenviados de um servidor para o navegador por padrão trafegam como texto simples, podendo ser facilmente capturados, ou até modificados. Por isso é importante que dados sensíveis não sejam transmitidos em formulários simples. No caso da tecnologia asp.net, que utiliza o conceito de viewstate (a persistência em dados de formulários HTML), as informações são criptografadas nas páginas aparece como uma seqüência de caracteres irreconhecíveis. É um bom exemplo de uso intenso de javascript combinado com funções de segurança e criptografia no lado do servidor. O fato do javascript rodar no navegador faz com que ele consiga ler informações sobre o estado da aplicação web, assim como histórico de navegação. A leitura de cookies de estado, junto com técnicas de uso de javascript injection faz com que seja possível o roubo de cookies que armazenam o identificador de uma sessão que está no servidor. Caso o código malicioso tenha sucesso nessa ação, e não tenham sido tomadas precauções adicionais no seu código, um segundo usuário poderia assumir o direito de acesso a um sistema sem que o usuário dono da sessão seja informado, simplesmente passando um link malicioso. Para evitar esse tipo de vulnerabilidade, uma boa opção é adotar o padrão cookieless nas aplicações. Isso fará com que o identificador sobre a sessão não fique armazenadas na máquina do cliente, e sim seja enviada a cada requisição pela url, utilizando método get. Além disso, por característica própria os códigos javacript têm capacidade indiretamente de ler (ou roubar) o histórico do cliente. Este fato é preocupante, pois demonstra uma invasão de privacidade perigosíssima, podendo ter conseqüências enormes, inclusive para espionagem. Seria possível baseado nesta premissa, por exemplo, ver as páginas de resultado que o cliente visitou, e desta forma direcionar publicidade específica baseada no comportamento do cliente. Uma ação parecida é possível em relação à leitura de cookies de dados, permitindo que se cruzado os dados destes com os do histórico, é possível determinar com relativa exatidão informações importantes sobre quem usa o computador. A técnica para leitura de histórico é bem interessante e inusitada, e demonstra claramente a capacidade criativa de programadores que utilizam brechas não tratadas. A síntese da técnica é: não podemos ler o histórico, mas dado um link, temos como saber qual a cor de link o navegador atribui a ele. Isso nos permite, sabendo que os links mudam de cor quando assumem o status visited (entre outros). Desta forma, temos como perguntar ao navegador qual a cor atribuída a um link que pode ser inserido uma área definida como invisível.

5 5 Código de exemplo de roubo de histórico: addevent( window, 'load', stealhistory ); var IEVisitedColor = '#cd0018'; var W3CVisitedColor = 'rgb(205, 0, 24)'; var websites = [ " " " " "more of your sites..." ]; function stealhistory() if(document.getelementbyid('site-list')) var List = document.getelementbyid('site-list'); for( var i = 0; i < websites.length; i++ ) var bremove = false; var ListItem = document.createelement('li'); var Link = document.createelement( 'a' ); Link.href = websites[i]; Link.id = i; Link.appendChild(document.createTextNode(websites[i])); ListItem.appendChild(Link); List.appendChild(ListItem); if( Link.currentStyle ) var color = Link.currentStyle['color']; if( color == IEVisitedColor ) bremove = true; else if( document.defaultview.getcomputedstyle( Link, null ) ) var color = document.defaultview.getcomputedstyle( Link, null ).color; if( color == W3CVisitedColor ) bremove = true; if( bremove == true ) List.removeChild(ListItem); else urchintracker( '/visited/' + websites[i] ); Fonte: Neste cenário, uma da opções para o usuário resguardar sua privacidade, seria desabilitar o javascript no seu navegador, ou até mesmo desabilitar algumas funções de javascript (disponíveis em alguns navegadores). Apesar de à primeira vista parecer uma boa opção, esta não é uma atitude recomendada, pois com as novas tecnologias implantadas nas aplicações web, o uso do javascript se tornou tão necessário a ponto de na maioria dos sites não se conseguir navegar com ele desabilitado, ou quando conseguimos, isso acontece com muitas restrições ou uma péssima experiência de navegação.

6 6 4. APLICAÇÕES SEGURAS COM JAVASCRIPT O desenvolvimento de aplicações web seguras envolve muitos aspectos. O quesito segurança deve estar presente desde o desenvolvimento do projeto, até nas diretivas de administração e alimentação de conteúdo da mesma por parte dos funcionários da empresa. Focando especialmente em javascript, o ponto mais crítico é a capacidade de injeção de código no aplicação. Esse tipo de ataque normalmente é executado de duas formas: via campos de entrada de dados em formulários, ou via URL(por exemplo enviando um link). Nos dois casos, o navegador irá rodar um javascript que não foi codificado pelo desenvolvedor do site, podendo ter ações maliciosas ou até mesmo alterando/excluindo conteúdo numa aplicação gerenciável. Uma das formas de se evitar esse tido de ação, no caso de formulários seria bloquear a entrada de códigos HTML ou javascript, ou então não decodificando essas tags. Na plataforma Asp.Net, por padrão não é aceita injeção de código HTML em formulário, podendo ser configurada para transformar as tags em texto simples. No PHP pode ser utilizada a função htmlentities para fazer o mesmo. Só esta implementação, já evitaria a maioria dos ataques, entretanto, muitos sites precisam permitir tags, e por isso precisam ter uma abordagem sobre entrada de dados diferente, passando a filtrar determinadas tags e liberar outras. No caso das injeções por URL, elas são geralmente aplicadas em aplicações que utilizam variáveis via GET para direcionar ações internas de aplicações. Isso é muito perigoso. Um desenvolvedor não deve, por exemplo, ter em sua aplicação uma URL assim: pois um link passado por um amigo, pode conter um código javascript que executa essa ação sem o consentimento do usuário, utilizando a sessão corrente do mesmo. É importante também destacar, que por mais que ofereça usabilidade, a validação de dados inseridos num formulário utilizando javascript deve ser sempre complementar à validação server side, já que o código que roda no navegador pode ser facilmente manipulado, criando brechas caso não haja a validação dupla. A verificação dos dados no servidor é importante, pois evita submissões de página sem necessidade, mas nunca deve utilizada como único meio de assegurar a consistência dos dados inserido.

7 7 4. FALHAS DE JAVASCRIPT NOS NAVEGADORES As falhas de segurança relacionadas a javascript nem sempre são de responsabilidade do desenvolvedor, pois ou da aplicação, mas também podem ser devido a falhas nos interpretadores javascript dos navegadores. Falhas são encontradas com freqüência, e normalmente corrigidas, mas sempre existirão novas descobertas. Muitas dessas falhas têm origem na necessidade de reconhecer erros, e mesmo assim "entender o que o programador gostaria de fazer e tentar contornar seu erro. Diferentemente de outras linguagens de programação, existe muita tolerância na programação de páginas web. Mesmo códigos errados funcionam devido aos esforços dos navegadores para tentar fazer a página aparecer na tela. Além disso, erros em navegadores web também moldaram as linguagens, quer dizer, programadores acabaram dependendo de erros para fazer as páginas aparecerem do jeito que queriam. Ainda hoje, os navegadores precisam detectar esses erros e saber o que o criador da página pretende. Altieres Rohr, especialista em segurança de computadores, G1 Falhas são descobertas com relativa freqüência e em alguns casos elas até permitem que seja rodado um código malicioso na maqui dos clientes, e em outros casos permitem ataques do tipo DoS. Recentemente foi descoberta uma falha no navegador Firefox, da Mozilla Fundation, no componente JIT(Just in Time). A empresa Secunia divulgou nessa terça-feira, 14/07, uma falha de segurança crítica no Firefox 3.5. O problema está na linguagem Javascript e pode ser porta de entrada para ataques remotos. Já está disponível na rede uma amostra do código de ataque. No entanto, ainda não foi notificada qualquer ação que tenha se aproveitado da falha em questão. Ainda assim, a Mozilla informou que deve ser lançada correção nos próximos dias Fonte:olhardigital.uol.com.br Muitas destas falhas descobertas são muito exploradas até que a empresa ou a imprensa tome conhecimento das mesma. Algumas têm nível moderado, mas outras podem chegar até mesmo a permitir que seja executado arquivo binário na máquina do cliente, através de estouro de memória (overflow).

8 8 5. CONCLUSÃO O javascript é um recurso muito útil e necessário, apesar de suas falhas ou possibilidades de mau uso por parte de desenvolvedores. Como toda linguagem, está em constante evolução e aprimoramento. Entretanto, deve-se ter cautela e saber das conseqüências de cada recurso usado em caso de tentativa de ataque, facilitando a prevenção. O uso de algum framework que gere e trate javascript é recomendável, pois libera o desenvolvedor pra pensar na lógica da aplicação, sem ter de ficar perdendo tempo em validações que são rotineiras e comuns, e que por isso devem ser padrões. Apesar disso, só o fato de se usar tal estrutura não dá uma garantia total de segurança, até mesmo por que ele não existe em nenhuma circunstância. Basta para isso lembrar que empresas de ponta como Google já foram alvos de ataques através de injeções javascript nas aplicações Orkut e Gmail, demonstrando o quanto o assunto deve ser levado a sério. Desabilitar ou javascript não é uma boa saída para o usuário, pois este perderá os melhores recursos e em alguns casos até mesmo o conteúdo de sites. O correto é sim que todos empreguem boas práticas, e contribuamos para o aperfeiçoamento deste excelente recurso para aplicações web. 4. REFERÊNCIAS [online] 17/06/ [online] 17/06/ [online] 17/06/ [online] 17/06/ [online] 16/06/ [online] 16/06/ [online] 17/06/ [online] 17/06/ [online] 15/06/ [online] 15/06/ [online] 17/06/ [online] 17/06/ [online] 17/06/ [online] 17/06/ [online] 17/06/ [online] 17/06/2010