Bem vindo ao SOS Designers

Faça o seu cadastro gratuito no Portal SOS Designers e tenha um acesso personalizado.

Empresas

Cadastre gratuitamente suas vagas, crie sua propria Lista de Curriculos Favoritos, e tenha um acesso personalizado.

Usuarios

Cadastre gratuitamente seu curriculo, crie sua propria Lista de Noticias Favoritas e tenha um acesso personalizado.

Área de Empresas | Vagas

Área de acesso a empresas cadastradas que desejam postar vagas de empregos no Portal e pesquisar curriculos.

Cadastre-se gratuitamente
Esqueceu a sua senha?

Área de Usuarios | Curriculos

Área do Usuario que deseja cadastrar seu curriculo e pesquisar vagas.



Cadastre-se gratuitamente
Esqueceu a sua senha?


Redes Sociais
Siga o Portal SOS Designers no Twitter Siga o Portal SOS Designers no Facebook

Segurança


Você está aqui: Home » Segurança » Brecha de Segurança – Autocompletar dos Navegadores

Brecha de Segurança – Autocompletar dos Navegadores


Pesquisar no Portal SOS Designers





Tempo Real



Siga o SOS Designers








pub_flash( 'http://www.sosdesigners.com/banners/web_flash_730x90.swf', 730, 90 ); " alt="Tecnoponta - 730 x 90 - - webdesign" />

Os navegadores modernos atuais competem entre si oferecendo uma serie de serviços em cima da especificação HTML (W3C) visando melhorar a experiência do usuário final. Os recursos de “autocompletar” são disponibilizados para personalizar melhorando a experiência de usuários na navegação na internet. Quando um navegador armazena as páginas visitadas ou memoriza campos e senhas dos seus sites favoritos, essas informações são consideradas “dados pessoais” e assim protegidas por algum recurso interno dentro do próprio sistema do navegador.


Para situações no qual o usuário final não deseje essa personalização, o próprio usuário é responsável por configurar instruindo assim no seu navegador de preferência para limpar seus dados pessoais. Para tal operação, o manual de uso do navegador de preferência deve ser consultado.


O recurso “autocompletar” é justamente um caso que abre uma vulnerabilidade de segurança na qual as informações digitadas pelos usuários são armazenadas dentro dos navegadores para reuso posterior. Um usuário despreparado pode deixar informações sensitivas armazenadas no navegador abrindo a possibilidade de ser usada maliciosamente.


É importante ressaltar duas coisas:


  1. Isso não é considerado uma “brecha de segurança” de nível de solução! Isso é um caso de vulnerabilidade acidental resultante do acréscimo deste serviço em cima da navegação de páginas na web.
  2. Não existe hoje tecnologia (plataformas, linguagem de programação ou protocolo de comunicação) que habilite uma solução web de controlar sistematicamente as configurações físicas feitas no navegador instalado na estação de trabalho do usuário. Na verdade isso nunca será possível por que é justamente a proposta do “modelo arquitetural” para soluções web no qual temos um servidor de solução gerando paginas dinâmicas dentro de padrão de visualização (HTML), usando um protocolo de comunicação padrão (HTTP) sem conhecimento ou controle do tipo do navegador requisitante, totalmente um independente do outro.


Baseado nisso, o que nos resta como responsáveis pelas soluções é buscar abordagens e ou alternativas para inibir tais brechas que possam ser geradas por tais circunstancias fora dos domínios da solução em si propriamente dita.


O recurso de “autocompletar” esta basicamente classificada em três tipos:


1-“Formulário Gerente:” é apresentado com uma caixa de diálogo para permitir que o navegador para armazenar informações de campos gerais. Se uma caixa de diálogo é apresentada, o usuário tem que conscientemente recusar a fim de evitar o armazenamento das informações.


2-“Password manager:” é apresentado com uma caixa de diálogo para permitir que o navegador para armazenar informações de campos de senhas. Se uma caixa de diálogo é apresentada, o usuário tem que conscientemente recusar a fim de evitar o armazenamento das informações.


3-“Histórico da sessão cachê:” os dados do formulário são armazenados no histórico da sessão para posterior recuperação. Quando os dados do formulário são armazenados em cachê no histórico da sessão, as informações que o usuário preencheu serão visíveis depois que o usuário tenha apresentado o formulário e clicar no botão “Voltar” para navegar à página do formulário original.


Problema


Como impedir sistematicamente o armazenamento de qualquer informação nos navegadores, uma vez que consideramos os usuários desprovidos dessa “expertise” mínima?


Solução 1 – “One Shot Password”


Criar uma senha dinâmica para cada acesso de usuário. A senha pode ser distribuída através de “Lista Definida”, “SMS” ou um hardware customizado como um “chaveiro token”. Nessa abordagem o navegador vai ficar livre para armazenar a senha digitada pelo usuário, que não será valida para uma próxima tentativa de autenticação.


Pontos Negativos:


  1. Custo com a compra e manutenção de uma solução que forneça o serviço de temporização dos tokens, mais as compra e distribuição dos dispositivos chaveiros para cada usuário.
  2. Integração da solução para trabalhar em conjunto com essa solução temporizador de token.
  3. Quando um usuário quebrar ou perder seu recurso de geração de tokens, ele não conseguira se autenticar na solução até refazer todo  procedimento de recadastro.


Solução 2 – Applet


Criação de um programa Java, assinado com certificado digital válido que executara embutidamente dentro do navegador do usuário para receber a digitação das informações. Nessa abordagem, o navegador não pode armazenar nenhuma informação por que os valores estarão sendo controlados dentro do programa Java embutido no navegador.


Pontos Negativos:


  1. A solução deixa de ser portável e passa a ser executando apenas em plataformas que tenha capacidades e compatibilidade com a instalação de JVM Java completa. Applet não é compatível BlackBerry, Windows Mobile, iPhone, iPad, Android e Symbiam. Ou seja, com essa abordagem só passaria a funcionar nos navegadores de desktops.
  2. Para habilitar a solução em dispositivos moveis teríamos que desenvolver uma solução nativa usando tecnologia proprietária de cada plataforma móvel – BlackBerry, iPhone, Windows Mobile , iPad, Android e Symbiam acessando a regras de negócio centralizadas no Container Java usando comunicação WEB SEVICES REST. Vale lembrar que alguns dispositivos móveis não tem portabilidade das próprias soluções proprietárias em versões diferentes de seus aparelhos e sistemas operacionais, podendo ter gerar diferentes soluções para diferentes versões do mesmo provedor. E finalmente teríamos que criar uma camada de integração WEB SERVICES REST na solução para ser invocado pelas diferentes aplicações nativas nas plataformas móveis.


Solução 3 – Autocomplete


Na especificação do HTML5 existe um recurso chamado “autocomplete” que usado para instruir o navegador a não armazenar aquela determinada informação. Todo componente visual (widget) pode ser programado com autocomplete=”off” dizendo para o navegador não armazenar aquele determinado campo. Documentação oficial - http://www.w3.org/wiki/HTML/Elements/input/text


O “autocomplete” foi proposto em 1999 pela Microsoft desde a versão do IE5 e só foi oficializado agora na data da especificação do HTML5 (2009) do W3C. Por ter sido proposto há muitos anos, esse recurso já é suportado pela maioria dos navegadores compatíveis com HTML3 e 4: Netscape 6.2 (Mozilla 0.9.4) or later, IE 5 or later e Chrome. Versões anteriores a estas não tem suporte.


Com esta abordagem, definiríamos os campos visuais de senha e assinatura do GF para usar “autocomplete”.


Pontos Negativos:


  1. Não existem 100% de garantia de suporte para HTML5 por ser a especificação do HTML mais recente. Os navegadores podem demorar o tempo que quiserem para implementar essa nova especificação.
  2. Mesmo depois da padronização com HTML5, alguns provedores de navegadores podem oferecer meios de manualmente desabilitar esse recurso.
  3. Podem existir navegadores HTML3 e 4 que não implementaram o recurso AutoComplete. Pela a pesquisa que eu fiz a maioria dos navegadores conhecidos já o usam o “autocomplete”, mas pode por exemplo haver um navegador (das muitos ofertados) para Android por exemplo que não o tenha feito.


Contorno Para os Pontos Negativos da Solução 3 – Autocomplete


É possível contornar algum pontos negativos gerados pelo “autocomplete”, adicionando alguns recursos de apoio. Seguem elas:


1 – A geração dinâmica de identificador widget e campos hidden na pagina HTML


Isso inibiria o navegador não compatível com autocomplete de reusar a mesma senha armazenada anteriormente. O navegador até poderia gravar a senha dentro dele, mas não apareceria nas futuras tentativas de autenticação.


Existe o risco dessas senhas em campos dinâmicos serem armazenadas e roubadas dentro desse tal navegador caso exista vulnerabilidades abertas dentro do software do navegador.


2 – Instruções de não cache HTTP


A instrução no HEADER do protocolo HTTP para não cachear da pagina e seus dados digitados em navegadores não compatíveis com autocomplete.


<meta http-equiv=“cache-control” content=“no-store” />
<meta http-equiv=“pragma” content=“no-cache” />
<meta http-equiv=“expires” content=“-1″/>


A especificação afirma que não existem garantias do navegador se ater. Veja o texto final da especificação HTTP:


“While the use of this directive might improve privacy in some cases, we caution that it is NOT in any way a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.”


Fica a critério de cada responsável pela solução escolher a melhor opção para seu cenário.


Link sobre o assunto – https://wiki.mozilla.org/The_autocomplete_attribute_and_web_documents_using_XHTML


 “Ponham em prática tudo o que vocês aprenderam, receberam, ouviram e viram em mim. E o Deus da paz estará com vocês”. Filipenses 4:9

Sobre o Colunista:

Fernando Franzini


Profissão: Projetista de Software e Consultor Java

Descrição: Fernando Franzini
Projetista de Software e Consultor Java
Cambridge PET, SCJA, SCJP, SCJD, SCWCD, SCBCD, SCMAD.
W3School XML, DOM, XSLT, HTML, XHTML, CSS, JavaScript, HTML DOM Developer.
Java Blog - http://fernandofranzini.wordpress.com

Deixe seu comentário:





© Copyright 2002-2017
Portal SOS Designers
Webmaster: Luiz Antonio Bovi