Direto do Editor

Direto do Editor | 09/05/2013 20h09 - Atualizado em 03/06/2013 19h07

Em nome da segurança, bancos deixam usuários inseguros

Os bancos brasileiros gostam de usar programas feitos na linguagem Java para dar mais proteção a quem utiliza o internet banking. O benefício do Java é ser multiplataforma, ou seja, a solução do banco é compatível com mais de um sistema operacional. Mas em vez de fornecer um programa totalmente em Java, os bancos fornecem apenas “plug-ins” de segurança e autenticação, que funcionam dentro do navegador web.

O problema é que o plug-in do Java tem sido, há alguns anos, o “atalho” mais utilizado pelos criminosos para conseguir invadir computadores e instalar vírus pela web.  Escrevemos sobre isso aqui na Linha Defensiva em 2009: como funcionam as infecções por applets Java.

Mas vamos supor que isso não importa. Afinal, não é mesmo culpa do banco que a tecnologia Java sofra desses males. Caberia ao usuário saber usar o Java de forma segura, ou então a Oracle, desenvolvedora do Java, deveria resolver as falhas do Java.

É aqui que começa o problema: a Oracle está, realmente, fechando os buracos do Java, com novos avisos de segurança, menos permissões para aplicativos sem assinatura digital válida, e outras medidas que deveriam ter sido tomadas quatro anos atrás.

Acontece, nesse momento, que até as aplicações dos bancos são classificadas como “possivelmente inseguras”. Muita gente vem questionando por que janelas de segurança estão sendo exibidas em sites de bancos. As janelas são como essas, abaixo. Não vou dizer o nome dos bancos, mas os clientes reconhecerão os avisos, caso os tenham visto:

Aviso de problema de permissão do Java em um um banco. (Foto: Reprodução)

Aviso de problema de permissão do Java em um banco. (Foto: Reprodução)

Aviso de problema de código do Java em outro banco. (Foto: Reprodução)

Aviso de problema de código do Java em outro banco. (Foto: Reprodução)

“Bloquear a execução de componentes possivelmente não seguros?”, pergunta o Java. Mas por que a pergunta? E por que agora?

Desde a atualização 21 do Java 7, lançada na metade de abril, o Java não permite mais algumas interações de código Javascript com código do Java. O Javascript é o código da própria página web, e executa livremente, porém com restrições. Já um aplicativo Java com assinatura digital é autorizado pelo usuário e executa com muito mais permissões. O Java não acha legal que esses dois códigos que são, digamos, de castas diferentes, se associem.

O que, de certa forma, faz sentido: alguns miniaplicativos do Java poderiam ser manipulados por Javascript em páginas de terceiros para realizar uma ação diferente daquela proposta.

Imagine a seguinte situação: alguém cria um aplicativo (applet) Java que faz downloads para o computador e abre o arquivo baixado. Ele é usado para baixar imagens. No entanto, por um erro, ele pode ser manipulado para baixar e executar programas. O código é confiável e assinado, mas pode ser usado de maneira insegura quando chamado por um site malicioso.

No site do banco, claro, não há risco algum. Mas e se o site não for o do banco? E se o aplicativo do banco tiver qualquer brecha que permita abuso?

Em tempo, a Oracle tem uma documentação para desenvolvedores (veja aqui, em inglês) para que esses avisos não sejam mais exibidos. Você não deve ler isso; seu banco sim.

O problema do costume

Nós não podemos nos acostumar com comportamentos inseguros, como ignorar avisos de segurança só porque eles partem de um site que conhecemos. Sites podem ser invadidos (fizemos essa brincadeira aqui na Linha Defensiva para mostrar isso) e sites de bancos podem ser redirecionados devido a problemas em modems ADSL ou até em provedores de internet. É justamente quando estamos em sites confiáveis que esse tipo de aviso não pode ser ignorado.

Por certo, um internauta deveria clicar em “bloquear” na janela acima. E o resultado é que ele ficaria sem poder usar o banco.

Quando os sistemas exigem de nós usuários um comportamento que, eventualmente, nos levará a ter um sistema inseguro, ele não colabora em nada conosco. E quando um sistema faz isso em nome da segurança, só podemos mesmo ter pena – de nós mesmos e das instituições que não veem a enrascada em que estão se metendo. Porque o usuário mal acostumado é o cliente dela.

Mas o problema não está no Java. Pelo contrário: o aviso que o Java vem exibindo é parte da solução. É preciso, porém, que o mercado aproveite essas soluções — e os bancos não têm sido exatamente pró-ativos nisso. Basta pensarmos nos domínios “.b.br”, mais protegidos contra redirecionamentos, que até hoje não são utilizados como endereços primários da maioria dos bancos1.

Recentemente instalei um driver para minha impressora. Eis o aviso do Windows:

Impressora usa componente sem assinatura digital. (Foto: Reprodução)

Impressora usa componente sem assinatura digital. (Foto: Reprodução)

Já tivemos notícias de sites invadidos e de programas de atualização defeituosos, que poderiam ser redirecionados. É esse tipo de verificação feita pelo sistema que impede componentes errados (e maliciosos) de serem instalados. E o motivo da não utilização do recurso de segurança é a preguiça, porque todos os fabricantes de impressoras têm certificados digitais — e o custo é por certificado, não por programa assinado.

Seja como for, lembre-se que um comportamento é inseguro mesmo quando um banco, um fabricante de hardware ou até mesmo quando uma empresa de segurança o obriga a fazê-lo. Não se acostume com o que é errado. Uma hora ou outra, o aviso será a última defesa.

Não se esqueça também de reclamar junto ao fabricante ou empresa. Nós não devemos confiar em nenhuma instituição cegamente, mas sim porque ela se faz confiável.

  1. O X da questão é que os bancos teriam de informar aos clientes que o ‘.b.br’ é ‘mais seguro’ que o endereço em uso atual. Isso deixa implícito que a solução atual não é 100% segura, e que a nova também não deve ser. Isso é simples e claro, mas não é algo que o cliente deve perceber, porque somos resistentes à mudança. As pessoas têm medo de acessar o banco pela internet, mas se esquecem de todos os riscos aos quais nos sujeitamos assim que colocamos os pés para fora de casa.
 

Comentários 7

Os comentários são de responsabilidade de seus respectivos autores

  • Jackson

    Muito bom o artigo, na primeira vez que vi este aviso no site do banco Santander fiquei meio que encucado de clicar em “não bloquear”, mas como tomo outros cuidados, telefonei para o SAC do banco pra saber se era seguro e somente após a confirmação do SAC é que prossegui com a operação.

  • Excelente artigo!

  • Marques

    Todas as vezes que abro a conta da Empresa recebo esta informação, só consigo ter acesso a conta quando permito: NÃO BLOQUEAR o que me deixa com dúvida se no meu PC tem alguma coisa errada, isto não deveria acontecer.

  • Parabéns, excelente artigo, é por estas e por outras, que acompanho o que você escreve, quer aqui quer no G1.

    Obrigado.

  • Victor

    O BB deveria se entender com a Oracle e adaptar o site para evitar que o usuário fosse obrigado a quebrar regras de segurança para acessar sua conta bancária. Sempre me sinto desconfortável ao ter que infringir regras de segurança para conseguir acessar detalhes de sites, ainda mais em se tratando de bancos.

  • tiago

    … assim permanece o problema, tanto os bancos quanto a oracle transferem ao cliente (que na maioria das vezes não tem a mínima idéia do que se trata) a responsabilidade de decidir ou não executar a aplicação. Assim permanecemos no impasse, ou aceitamos e corremos o risco para poder acessar o banco, ou bloqueamos mas somos impedidos de realizar as transações via internet.

  • Não há quem aguente ficar instalando infinitos adicionais a cada vez que se formata o computador, atualiza o navegador ou simplesmente muda-se de rede.

    Para os corajosos, ou conscientes, vai uma dica: você pode ligar no banco e pedir para desabilitar todas as verificações de segurança. Dessa maneira, você não precisa de mais nada além da sua senha.

    Vai encarar? :-P

    Ah, muito bom o artigo!

Alertas no Twitter

 
Parceiro
Site Seguro

Anuncie | Termos de Uso | Politica de Privacidade | WP

Editado por Altieres Rohr. Mantido pelo Staff Linha Defensiva

Contato Geral:

English ©2004-2015 Linha Defensiva. Todos os Direitos Reservados.