Velhas falhas, novas técnicas: Error Based SQL Injection

Este artigo também está disponível para leitura on-line ou download em formato PDF.

Por Ulisses Castro | Conviso Security Labs

Todos que já buscaram saber como funcionam os ataques de SQL Injection sabem que é uma técnica antiga, porém sempre é bom ver novas ideias surgindo que acabam servindo para ampliar as possibilidades. Quero compartilhar aqui algumas técnicas não convencionais de extração de dados que normalmente são utilizadas por "seres humanos", mas porque dizer assim?

Por mais acostumado a automatizar tudo utilizando as melhores e mais variadas ferramentas para pentest, você não pode esquecer que em algumas das muitas situações encontradas durante o processo, é manualmente e com aquele pensamento "fora da caixa" que vai conseguir um resultado inesperado e diferenciado de qualquer outra abordagem similar no mercado.

Por isso venho aqui compartilhar uma técnica semelhante a utilizada no MS-SQL Server que é bem conhecida para quem tem experiência em ataques neste tipo de banco de dados, entretanto pouco conhecida e utilizada em outros, em específico MySQL, Oracle, PostgreSQL e SyBase que é o Error Based Blind SQL Injection, nada mais do que a extração de dados baseada em erro.

Ferramentas fechadas de renome e também aquelas que tem seu código fonte aberto não abordam tal técnica, perdendo uma grande gama de possibilidades e acabam não suprindo um gap que nós pentesters encontramos. Apesar de não abordar neste artigo especificamente como utilizá-la em conjunto com outras técnicas para bypass em Web Application Firewalls (WAFs), deixo aqui algumas ideias que passam batido em muitos WAFs como HPP em conjunto com SQL Injection e existem até aqueles que deixam passar SQL Injection com erros boleanos pois na assinatura só conseguem se defender quando encontrarm o famoso UNION na URL, fica aqui um gancho para uma próxima pesquisa.

Introdução

Partindo do princípio que o leitor sabe do que se trata um SQL Injection, vamos deixar claro as seguintes técnicas de maneira resumida:

• Union Inband SQL Injection: Técnica onde ao injetar códigos SQL através de uma aplicação, buscamos utilizar a função UNION em conjunto com operadores boleanos para imprimir os dados solicitados na própria página da aplicação.


• Blind SQL Injection: Diversas formas diferentes, basicamente utilizando comparações boleanas em conjunto com funções de string do banco de dados, forçamos um verdadeiro ou falso na aplicação montando corretamente ou não a página.


• Error Based Blind SQL Injection: Este tipo ataque, o qual vou abordar neste artigo, é exatamente o tipo que é pouco abordado em ferramentas, onde muitas vezes não conseguimos trazer os dados utilizando o UNION, mas sim forçar que algum erro seja impresso na página.

Sendo assim existem algumas técnicas para extrair os dados destas mensagens. Importante frisar que as demonstradas utilizando este tipo de ataque podem facilmente ser adaptadas para o Blind SQL Injection e também o conhecido Time Based SQL Injection, que se baseia no tempo em que é retornada determinada consulta sem enxergar absolutamente nada na interface da aplicação.

Error Based Blind SQL Injection, como funciona?

MySQL

Vamos ver como poderíamos forçar um erro boleano no MySQL e extrair dados do mesmo? O pesquisador Dmitry Evteev, apresentou uma técnica muito interessante utilizando a função ExtractValue() do mysql versão 5.1 ou superior para demonstrar como extrair dados. No console do MySQL podemos ver o que ocorre ao forçar um erro utilizando a função apontada, repare que não é utilizado UNION, conforme apresentado na imagem abaixo.



Esta abordagem é excelente, porém só conseguimos extrair os dados em versões 5.1 ou mais recentes, a quantidade de dados extraída é limitada a 31 bytes e ainda alguns casos dependemos de um UNION o que é péssimo frente a defesas como WAFs. Abaixo, um exemplo demonstrando a limitação dos 31 bytes:



Para as limitações citadas existem diversas formas de amenizar estas dificuldades, primeiro é preciso eliminar a dependência de versão. Abaixo um insight feito por Qwazar que demonstra como é possível realizar esta técnica aplicada para versões do MySQL 4, 5.0, 5.1 e superiores. Tal abordagem além de mitigar a limitação da versão, amplia a quantidade de bytes extraídos passando de 31 para 64 bytes e mantém a mesma lógica demonstrada acima:



Porém nos traz mais uma desvantagem, neste caso devido a função rand(), não existe 100% de chance de retorno, ou seja, as vezes o resultado pode vir e as vezes não. Isso é péssimo, principalmente em casos onde escrevemos um script para automatizar mas como sempre existe uma solução, abaixo montei uma versão sem utilizar UNION e mantendo 99% de retorno do resultado. Não sou DBA e nem mesmo ultra expert em SQL, assim acredito que alguém com mais experiência possa ajudar a montar um consulta um pouco menor, mas a syntax ficou assim (seguindo o mesmo exemplo acima):

select '1 ' and if(row(0,0)> (select + count(*), concat((select concat_ws(0x3a,user,password) from mysql.user limit 1), 0x3a, floor(rand()*2)) x from mysql.user group by x limit 1),1,if(row (0,0)> (select + count(*),concat((select concat_ws(0x3a,user,password) from mysql.user limit 1),0x3a,floor(rand()*2)) x from mysql.user group by x limit 1),1,if(row(0,0)>(select + count(*),concat((select concat_ws(0x3a,user,password) from mysql.user limit 1),0x3a,floor(rand()*2)) x from mysql.user group by x limit 1),1,if(row(0,0)>(select + count(*),concat((select concat_ws(0x3a,user,password) from mysql.user limit 1),0x3a,floor(rand()*2)) x from mysql.user group by x limit 1),1,if(row(0,0)>(select + count(*),concat((select concat_ws(0x3a,user,password) from mysql.user limit 1),0x3a,floor(rand()*2)) x from mysql.user group by x limit 1),1,if(row(0,0)>(select + count(*),concat((select concat_ws(0x3a,user,password) from mysql.user limit 1),0x3a,floor(rand()*2)) x from mysql.user group by x limit 1),1,if(row(0,0)>(select + count(*), concat((select concat_ws(0x3a,user,password) from mysql.user limit 1), 0x3a, floor(rand()*2)) x from mysql.user group by x limit 1),1,if(row(0,0)>(select + count(*),concat((select concat_ws(0x3a,user,password) from mysql.user limit 1),0x3a,floor(rand()*2)) x from mysql.user group by x limit 1),1,if(row(0,0)>(select + count(*),concat((select concat_ws(0x3a,user,password) from mysql.user limit 1), 0x3a,floor(rand()*2)) x from mysql.user group by x limit 1),1,(select 1 and 1=1))))))))));

Veja que o resultado apresentado na imagem abaixo não vem truncado em 31 bytes e conseguimos ver a hash completamente, pois conseguimos trazer 64 bytes. Essa talvez não seja nem de perto a melhor solução e seria preciso estudar um pouco mais algumas formas de melhorar os resultados.



Com a utilização desta técnica, em conjunto com outras funções específicas do MySQL, é possível ampliar ainda mais extração de dados. Utilizando a função compress() com a biblioteca zlib podemos compactar o resultado, conforme apresentado abaixo. Com isso, é possível diminuir o tamanho do resultado, o que nos testes que realizei chegaram a 50% de taxa na compressão. Porém, a desvantagem é que não seria possível utilizar técnica de Verdadeiro/Falso para extrair caractere por caractere, pois o tipo de dado de retorno impede que isso aconteça.



Porém a solução é simples, com a função hex() conseguimos transformar todo o resultado em hexadecimal, e com esta saída não só podemos transportar qualquer tipo de dados como ainda facilita a comparação Verdadeiro/Falso em casos de Blind SQL Injection, e pode preparar a consulta para trazer um "tira" única em hexadecimal de todos os dados solicitados independente do tamanho.



A única desvantagem perceptível é que o processamento do banco de dados será elevado em caso de automatização, mas isso pode ser ajustado através de delays e timers. Na prática para extrair os dados, seria necessário "caminhar" pela tira em hexadecimal, extraindo o resultado de 64 em 64 bytes ou 32 em 32 bytes dependento da técnica, utilizando funções específicas para lidar com strings. Na prática ficaria como na imagem abaixo:



E para potencializar tudo isto seria possível ainda utilizar "sub-querys" e trazer muitos dados com pouquíssimos "hits" no Servidor Web, técnica que demonstrei no OWASP AppSec Brasil do ano passado. Porém nem todas as empresas utilizam MySQL e é preciso estar preparado para encontrar os mais diversos tipos pela frente. Acima demonstrei como é feito com MySQL, porém cada um possui sua limitação e também vantagens, o que nos traz novas possibilidades a cada abordagem.

Aplicação em outras bases

Abaixo algumas idéias menos elaboradas do que esta feita no MySQL, porém mostrando a pontinha do iceberg e um caminho para aplicar a mesma técnica em diferentes cenários.

MSSQL Server / Sybase

Não é nada novo, a maioria das técnicas de SQL Injection demonstradas em diversos forums, how-tos, listas de discussão, demonstram esta técnica que força a conversão no tipo de dado para demonstrar o erro, no caso do MSSQL é possível trazer aproximadamente 1024 bytes e no Sybase a técnica é a mesma.

PostreSQL

Semelhante ao MSSQL/Sybase, porém utilizando a função CAST():



E seguindo a mesma linha de raciocínio aplicada no MySQL:

Oracle

Demonstrando esta técnica utilizando Oracle 9.0 ou superior, é possível extrair até 214 bytes de uma mensagem de erro no Oracle usando a função XMLType() em conjunto com outras para tratamento de string, seguindo lógica semelhante a demonstrada com o MySQL, transforma a consulta em hexadecimal, usa substr() para cortar a "tira" e trazer os resultados em partes. E ainda podemos utilizar um truque para trazer versão em uma única linha, isso porque o Oracle não possui offset ou limit:

SELECT banner FROM(SELECT banner,rownum rnum FROM v$version a)WHERE rnum=1;

Usar XMLType() para mostrar a versão na saída de erro, para isto foi necessário utilizar a função REPLACE() e substituir os espaços por "_"(underline). Repare que a todo momento utilizo a função CHR() visando evitar qualquer problema com caracteres de "'"(aspas simples).

SELECT XMLTYPE(CHR(60)||CHR(58)||(SELECT REPLACE((SELECT banner FROM(SELECT banner,rownum rnum FROM v$version a)WHERE rnum=1),CHR(32),CHR(95))FROM dual)||CHR(62))FROM dual;

Abaixo uma versão mais apurada para burlar os problemas de tipos de dados, assim como replicar técnica semelhante à aplicada ao MySQL, utilizando conversão para hexa e removendo a função REPLACE() não precisamos dela já que estamos convertendo para hexadecimal.

SELECT UPPER(XMLTYPE(CHR(60)||CHR(58)||(SELECT RAWTOHEX((SELECT banner FROM(SELECT banner,rownum rnum FROM v$version a)WHERE rnum=1))FROM dual)||CHR(62)))FROM dual;

E finalmente a versão para ser utilizada em um Error Based Blind SQL Injection utilizando operador lógico simulando um ataque.

SELECT 1 FROM dual WHERE 1=1 AND(1)=(SELECT UPPER(XMLTYPE(CHR(60)||CHR(58)||(SELECT RAWTOHEX((SELECT banner FROM(SELECT banner,rownum rnum FROM v$version a)WHERE rnum=1))FROM dual)||CHR(62)))FROM dual);

Existem diferentes maneiras de se chegar ao mesmo objetivo, com um conhecimento maior em determinado banco de dados e mais pesquisas, com certeza é possível chegar a um resultado mais apurado, lembrando que em todos os casos sempre pensei em não utilizar o UNION para tentar evitar um possível match de assinatura com WAFs, assim como a utilização de função para representar caracteres ascii na consulta e evitar enviá-los através de URL.

Conclusão

SQL Injection é uma técnica que por mais antiga que seja a cada dia evolui, seja com lançamento de novas versões com novas funções, ou fazendo uma releitura de técnicas já conhecidas e aprimorando sempre é possível demonstrar algo novo.

E como sou um viciado convicto em Python nada melhor do que escrever scripts em python usando threads somado a técnicas novas, é sempre diversão garantida. Abaixo o video demonstrando na prática um script que aplica a técnica acima, atacando um banco de dados MySQL.



Em um futuro próximo a Conviso IT Security estará disponibilizando em formato Open Source algumas ferramentas criadas em laboratório, fique de olho! ;)

Referências

• http://www.owasp.org/index.php/SQL_Injection


• http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet


• http://www.owasp.org/index.php/AppSec_Brasil_2009_%28pt-br%29#tab=Arquivos_das_Apresenta.C3.A7.C3.B5es


• https://forum.antichat.ru/printthread.php?t=119047&page=2&pp=10


• http://ptresearch.blogspot.com/2010/01/methods-of-quick-exploitation-of-blind_25.html


• http://qwazar.ru/?p=7

Esclarecimento sobre o ISSA Day

Recebemos mensagens, tweets e telefonemas de algumas pessoas em dúvida sobre o ISSA Day no dia 31 de agosto, lá no Genuíno. Para deixar claro, é isso mesmo, a entrada é de graça e ao final será liberado um happy hour para os presentes com direito a chopp e canapés custeados pela gente, além do sorteio de uma vaga para o curso "Web Hacking Techniques" promovido pelo Conviso Security Labs.

Faça a sua inscrição e compareça, o o evento será uma oportunidade de conhecer a experiência de várias pessoas na Defcon e Black Hat, networking e comida grátis no final. Quando é que você tem uma chance como essa em plena 3a feira? :-)

ISSA Day Agosto 2010

Estamos patrocinando o ISSA Day que irá acontecer no dia 31/08 no Genuíno, em São Paulo, SP. O evento é gratuito e aberto a qualquer interessado, a chamada está no web site da ISSA Brasil e teremos a seguinte agenda:

• 19h00 – Credenciamento


• 19h30 – Palestra da ISSA - Por que ser ISSA?


• 20h00 – Abertura falando sobre a Conviso.


• 20h15 – O processo de segurança em desenvolvimento, que não é ISO 15.408


• 21h00 – Palestra sobre a Black Hat e Defcon


• 21h45 – Sorteio de Treinamento Conviso e Encerramento – Com HH

Responsabilidade Compartilhada

Este artigo está também disponível em formato pdf para leitura on-line ou download.

Introdução

Quando uma empresa tem uma ou mais vulnerabilidades do seu Ambiente Informatizado exploradas por um atacante, as conseqüências podem ir da exposição negativa da imagem perante a sociedade até prejuízos financeiros decorrentes da parada de um processo, como no caso de um comércio eletrônico.

Mas quando este incidente também afeta os clientes das empresas, o que pode acontecer e como este risco pode ser reduzido a um nível aceitável? Ocorrências desta natureza tem aparecido com freqüência e retirando os casos onde as pessoas são vitimadas por quadrilhas especializadas em phishing [1], cenários agressivos aparecem no Brasil:

• Em agosto de 2010 mais de cinco milhões de web sites hospedados em um provedor estavam sendo utilizados para propagação de malware [2], e no Brasil os web sites das empresas Vivo e Oi [3] sofreram ataques similares.


• Dados pessoais de 12 milhões de pessoas que participaram do Exame Nacional do Ensino Médio (ENEM) vazaram de uma base de dados restrita, expondo-as a serem vítimas de crimes virtuais, como furto de identidade. [4]

O que está acontecendo

Como resultado, algumas pessoas tem utilizado instrumentos presentes no Código Civil e no Código do Consumidor para buscar reparações em diferentes esferas. Em alguns casos, a responsabilidade é compartilhada não só pela empresa que hospedava o componente onde o problema foi gerado, mas ainda outras envolvidas no processo de alguma forma [5]. A elaboração de leis e regulamentações que definam regras para este cenário como forma de garantir a aplicação de critérios legais para os negócios on line, vem sendo conduzida em diversas iniciativas.

Em especial sobre falhas em aplicações podem ser interpretadas no âmbito dos processos contra empresas envolvidas, é interessante destacar duas notícias que mostram o que podemos esperar de um futuro próximo:

• O Comitê Gestor da ICP-Brasil busca a aplicação de certificados digitais nos códigos dos aplicativos de interatividade desenvolvidos por diversas empresas para a TV Digital como forma de garantir a autoria e a responsabilidade civil [6].


• Uma empresas de rastreamento e bloqueio de veículos por satélite foi condenada a restituir um de seus clientes, uma vez que o sistema utilizado para suportar o processo falhou e permitiu o furto de um caminhão. [7]

Uma proposta de mudança

Uma vez que as falhas em aplicações representam hoje entre 75% a 92% dos ataques realizados através da Internet [8], e as empresas buscam posicionar seus recursos cada vez mais através de interfaces web, o que fazer para ter aplicações mais seguras e reduzir o risco de impactos diretos e colaterais da exploração de vulnerabilidades?

Onde as fábricas de software falham

As fábricas de software deveriam implementar controles que garantissem a remoção de vulnerabilidades óbvias de seus produtos, e não é isso que tem acontecido. Desde a sua primeira edição em 2004, o OWASP Top 10 [9] apresenta falhas persistentes em aplicações web e disponibiliza projetos para que estas sejam corrigidas ainda no ciclo de desenvolvimento, mas elas ainda ocorrem freqüentemente.

As causas estão todas na inexistência de um ciclo de desenvolvimento seguro, onde não existem controles que verificam o nível de segurança dos releases desenvolvidos, como ainda é comum a ausência de processos que garantam a capacitação contínua dos desenvolvedores como forma de aumentar gradativamente a qualidade da segurança embutida no produto.

Mas antes de se apontar o dedo para as fábricas de software, existe um ponto que deve ser considerado com o mesmo peso para uma avaliação: o que as empresas que compram software tem feito para mudar este cenário?

Onde as empresas falham

Segurança e performance são competências antagônicas que devem ser equilibradas para garantir o atendimento às necessidades do cliente dentro de um nível de segurança adequado. Para garantir o resultado aceitável desta equação, é necessário investir em um esforço similar ao empregado para outras atividades de suporte ao produto final comuns no desenvolvimento de software, tais como design de interface e conectores com produtos de mercado. O problema é que esta necessidade não é atendida pelas empresas.

O Ponemon Institute publicou a pesquisa “State of Web Application Security” citada anteriormente neste artigo, que foi realizada com 638 empresas de grande porte nos Estados Unidos e mostrou uma realidade que atesta a afirmação anterior:

• Quase 70% dos entrevistados não consideram que o orçamento para segurança das aplicações web é suficiente.


• Das vulnerabilidades consideradas urgentes nas empresas, 34% não são consertadas e 55% dos entrevistados acreditam que os desenvolvedores são ocupados demais com outras atividades para adequar as falhas de segurança.

A Responsabilidade Compartilhada

Seria inocente esperar uma mudança imediata dos dois lados mediante esta situação, uma vez que são necessários recursos extras aos já previstos e o atendimento de um nível de maturidade que só o tempo permite chegar. Porém existe pelo menos uma ação que pode ser tomada para mudar este cenário: assumir a responsabilidade compartilhada.

A primeira ação a ser considerada, é estabelecer contratos que deixem claro quais são os papéis de cada um. O OWASP Legal Project [10] apresenta o “OWASP Secure Software Development Contract Annex” como um modelo para ser utilizado nesta ação.

O objetivo do documento é servir de base para garantir o atendimento de um nível de proteção adequado para o software através da definição de papéis no processo de desenvolvimento, estabelecimento das áreas onde os controles de segurança devem ser considerados e ainda formalizar o uso de testes e recursos técnicos específicos.

Mais do que uma ação isolada e ineficaz para injetar a responsabilidade pela segurança das aplicações para um dos dois lados, é fundamental entender que a mudança será atingida se algumas premissas forem aceitas e consideradas como base para o processo.

Níveis de proteção racionais

O contrato deve prever que o nível de proteção do software irá variar de acordo com o seu nível de criticidade. Aplicações diretamente relacionadas ao negócio da empresa ou que estejam sujeitas a uma regulamentação, potencialmente serão mais críticas que as demais. Aplicar o mesmo nível de proteção em todos os produtos não é uma ação racional e muito provavelmente vai fazer a fábrica de software alocar um esforço que poderia ser evitado, e a empresa irá pagar esta conta.

Com isso, o programa será em pouco tempo criticado com razão, considerado um custo desnecessário e eliminado. É fundamental ter critérios adequados de onde, como e com qual nível de rigor os controles deverão ser aplicados.

Compartilhamento de atividades

Para que as responsabilidades sejam compartilhadas, é fundamental que o mesmo ocorra com as atividades relacionadas. A fábrica de software deverá ter um processo de desenvolvimento seguro como parte do processo, porém a empresa que adquire a aplicação tem como obrigações mínimas garantir que o processo de desenvolvimento seguro não será atropelado por motivos de negócio que não considerem todo o trabalho de planejamento estabelecido. Se for realmente necessário, a área solicitante deve formalmente - ou mesmo legalmente? - assumir a responsabilidade por isso.

Além disso, os componentes de arquitetura utilizados devem passar pelos mesmos critérios de segurança, uma vez que falhas e vulnerabilidades nestes componentes podem comprometer o nível de segurança do software.

Evolução contínua

O processo deve ser pensado como algo que irá aumentar o nível de rigor de forma crescente e contínua. Os termos apresentados no exemplo do documento publicado pelo OWASP devem ser considerados como uma base para ser adaptada pelos advogados de cada empresa, o que irá variar muito não só pelas características organizacionais, mas ainda de acordo com o mercado de atuação e regras setoriais específicas (ex. PCI DSS).

Uma proposta racional é estabelecer métricas de acompanhamento e reuniões de status entre às partes, onde a meta de atingir um nível de excelência no desenvolvimento seguro poderá ser atingida aos poucos. Todas as metodologias de desenvolvimento seguro apresentam propostas para este tipo de controle, é buscar o que for mais adequado para a realidade de cada empresa e adaptar.

Conclusão

Este artigo é uma provocação com uma sugestão e deve ser entendido desta forma. Certamente, a primeira pergunta que surge na leitura é: quem paga esta conta?

A primeira resposta acaba sendo a comum a produtos com melhorias: o cliente final. Porém, vale pensar em todo este processo como um modelo de negócios, algo que irá potencializar os produtos em um mercado onde estabelecer e garantir um nível de segurança adequado é algo desejado por todos os clientes que usam a Internet para suas transações.

No começo da Internet os provedores eram pagos e quem conseguia um preço menor com nível de qualidade similar (ou mesmo inferior ...) a seus concorrentes abocanhava boa parte do mercado. Um dia uma grande empresa decidiu prestar o serviço de graça para a sociedade, e o modelo ruiu. Com a evolução dos processos legais e a potencial perda de clientes para concorrentes que apresentam um nível de segurança superior - ainda que esta impressão exista por nunca terem sofrido uma perda - quem ficar para trás vai acabar pagando uma conta bem mais cara.

Sobre o Autor

Eduardo Vianna de Camargo Neves trabalha com Segurança da Informação desde 1997, tendo atuado como auditor, consultor e Security Officer. É sócio-fundador e Gerente de Operações da Conviso IT Security, responsável pela administração e estratégia da empresa. Serve ainda como membro do Capítulo Brasil do OWASP, do OWASP Global Education Committee na América Latina e voluntário no (ISC)2.

Novo vídeo no Canal Conviso IT Security

Quando um servidor de aplicação aceita o método PUT, é possível que um atacante envie arquivos com conteúdo e finalidades diversas, inclusive scripts que possibilitam a execução de códigos na máquina alvo. Este vídeo mostra como o ataque ocorre, servindo como ferramenta de instrução para as equipes responsáveis pela administração de segurança.

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>
<script>
$(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();

});

</script>
</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/.


2. 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.


3. 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


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


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

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.

Exposição de Dados em Segurança nas Nuvens

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

Introdução

Perguntas sobre segurança na nuvem e viabilidade do armazenamento de informações críticas em serviços baseados na web foram levantadas após um incidente que envolveu o Twitter [1] e o Google Apps [2], onde um cracker obteve e distribuiu mais de 300 documentos confidenciais, relativos ao Twitter, que estavam armazenados nos aplicativos do Google [3].

De acordo com o analista do Gartner, John Pescatore [4], os clientes devem lembrar que o Twitter e a maioria dos aplicativos do Google, até 18 meses atrás, foram desenvolvidos para o compartilhamento de informações e não para proteger as informações e evitar que elas sejam transferidas. Com a recente oferta de software que rodam na nuvem, é comum surgirem dúvidas sobre que software deve ou não ser hospedado na web ou se no futuro todo software estará instalado somente na grande rede.

Um exemplo recente foi o cancelamento da prova do Exame Nacional do Ensino Médio (ENEM). Segundo o Jornal Estado de São Paulo [5], uma falha do Instituto Nacional de Estudos e Pesquisas Educacionais (INEP) permitiu acesso livre aos dados pessoais de 12 milhões de inscritos nas últimas três edições do Exame.

O que é mais grave é que, ao ser avisado pelo Jornal, o INEP afirmou que os dados seriam acessados apenas pelas instituições de ensino, mediante identificação e senha. Isto é, aparentemente, não foi feito nenhum teste, pois, se tivessem sido realizados testes básicos, a falha teria sido facilmente identificada. Seguindo ainda essa teoria, o que poderia ter sido feito era tratar a segurança da informação como um processo, considerar todas as dimensões e ter um profissional com experiência nesta prática como parte da equipe do projeto com a autonomia e autoridade adequadas [6].

Ensinando Privacidade

Quando falamos de privacidade, o que nos preocupa de imediato são as milhares de câmeras que nos seguem onde quer que estejamos, o sinal do celular que registra em que regiões da cidade estamos, é o acesso indevido aos nossos dados armazenados nos órgãos do governo, bancos e nas empresas com as quais transacionamos e tudo onde tem nossa informação. Porém, precisamos aprender que privacidade começa com a atitude de cada pessoa. Nestes últimos dias têm sido divulgadas notícias onde as pessoas não cuidam da sua privacidade de forma adequada e sofrem conseqüências.

O primeiro caso conta que dois adolescentes, de livre e espontânea vontade, se colocaram à frente da câmera do computador, se conectaram na TwitterCam e começaram a trocar carícias íntimas e se exoborem em cenas próximas ao sexo explícito. Em pouco tempo, além dos assistentes on line, milhares de pessoas viram as cenas em site de divulgação de filmes. Como são menores de idade, irão receber punição cabível, mas, em função das regras da nossa sociedade, a garota é quem está sofrendo mais e segundo reportagens, a família pensa em mudar de cidade. Ainda em seu blog, Edison Fontes, CISM, CISA, chega a uma conclusão de que é necessário ensinar privacidade. “Precisamos ensinar às pessoas que não podemos colocar a culpa nos outros e na imprensa por divulgar notícias que foram geradas pelas próprias pessoas”.

Realmente existe Segurança nas Nuvens?

Um dos maiores riscos da computação em nuvem é o desconhecido, já que muitos fornecedores são empresas relativamente novas ou oferecem serviços em nuvem há pouco tempo. "Cada companhia é diferente, começando por quanto cada uma investe em segurança, com base em tamanho e crescimento e também na sofisticação do grupo de gerenciamento", diz Cakebread, ex-Salesfroce. Mark Nicolett, vice-presidente de pesquisas da Gartner, relata que o foco dos fornecedores está, em primeiro lugar, em suas capacidades principais, como backup de dados ou entrega de aplicativos para Recursos Humanos: "A segurança é, geralmente, o último componente adicionado à uma nova tecnologia, e em computação em nuvem não foi exceção"[6].

A Computação nas Nuvens ou Cloud Computing é considerada uma evolução natural da computação atual e onde, a cada dia, empresas investem em ritmo crescente nesta tecnologia. Uma das principais vantagens é a virtualização de produtos e serviços computacionais, proporcionando uma redução dos altos custos com tecnologia e infra-estrutura local, além disso, as empresas ganham praticidade e versatilidade, pois os serviços são obtidos de maneira mais fácil e transparente [7]. Abaixo segue um vídeo demonstrativo e ilustrativo de Segurança nas Nuvens, abordando alguns temas conhecidos da web:

Conclusões

Caso ainda se pergunte se vale a pena expor seus dados em sites de relacionamento e meios de comunicação, vale do ponto de vista profissional, como é o caso do LinkedIn [9]. Nele você monta um currículo online, onde pode ter uma rede de amigos onde possa compartilhar informações profissionais e fazer indicações para o mercado de trabalho. Fontes como essas são válidas, porém deve-se manter o mínimo de segurança possível para não expor informações privadas de sua empresa e de si próprio.

A Segurança da Informação é um bem necessário e todos devem manter-se antenados. Já com a Segurança nas Nuvens, é preciso uma abordagem e segurança diferentes, referenciando sempre que os dados e aplicativos que são utilizados estão expostos na web, onde todos podem ter contato e estão mais vulneráveis a perdas e furtos. Ou seja, não basta ao usuário se preocupar em onde ele vai acessar esses dados (Lan Houses ou Cafés), e sim em como é tratado esse tipo de informação, se ele se preocupa em como isso é confidencial (no caso do seu login e senha), na integridade dos dados (vazar informações confidenciais em um site de relacionamentos) e da disponibilidade relacionada (assegurar que apenas as pessoas que tem acesso possam visualizar suas informações).

Referências

[1] http://www.twitter.com

[2] http://www.google.com/apps

[3] http://www.ipnews.com.br/voip/infra-estrutura/seguranca/invas-o-do-twitter-e-do-google-apps-levanta-questoes-sobre-seguranca-em-nuvem.html

[4] http://convergenciadigital.uol.com.br/cgi/cgilua.exe/sys/start.htm?infoid=20210&sid=15

[5] http://www.itweb.com.br/blogs/blog.asp?cod=58

[6] http://www.itweb.com.br/noticias/index.asp?cod=62822

[7] http://www.fatecjp.com.br/revista/art-ed02-001.pdf

[8] http://www.youtube.com/watch?v=8RMWO9JxZjA&feature=related

[9] https://www.linkedin.com

Sobre o Autor

André Kos atua com informática desde 2003, acumulando experiência em consultoria e processos de Help Desk. Iniciou suas atividades na Conviso IT Security em 2008, onde trabalha como Gerente de Projetos, responsável por coordenar as atividades da equipe de consultoria e a troca de conhecimento com o Conviso Security Labs.

Patrocínio do OWASP AppSec Brasil 2010

Dando prosseguimento ao sucesso da primeira AppSec Brasil, que ocorreu em Brasília em 2009, o Capítulo brasileiro do OWASP irá promover a segunda edição em 2010, na cidade de Campinas, onde espera reunir um número expressivo de profissionais e pesquisadores brasileiros e latino-americanos para compartilharem informações sobre o estado-da-arte da segurança de aplicações.

A Conviso IT Security patrocina pelo segundo ano consecutivo a edição do AppSec Brasil, contribuindo para fomentar as discussões sobre segurança em aplicações no Brasil e suportando o OWASP em sua missão de tornar este aspecto visível o suficiente para que as pessoas e organizações possam tomar decisões suportadas pelo conhecimento dos riscos de segurança que podem existir nestes componentes.

Got OWASP?