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:

“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 bancos[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.].

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

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.