O que uma empresa tem de mais valioso é sua base de clientes e consumidores. No caso de uma empresa que trabalha com venda direta e diz trabalhar com multi-níveis – cof cof pirâmide financeira cof cof – , essa base é ainda mais preciosa e seus dados devem ser tratados sempre com o maior cuidado possível.
Se tratando de uma empresa com atividades ainda duvidosas tais dados são extremamente sensíveis, tendo em vista que muita gente não gostaria de ter seu nome associado às atividades da empresa e pior ainda, revelados a quem quer que seja.
Pois bem, fazendo uma busca sobre as atividades da empresa no Google – pois fiquei sabendo da recente mudança para S/A e queria checar – eu esbarrei em algumas páginas e não consegui acreditar. Não que os dados apresentados sejam extremamente relevantes ou absurdamente secretos, mas pela simplicidade que seria evitar que isso ficasse exposto. Me lembrou imediatamente que a empresa, dias atrás, teve um recurso não julgado por ausência do pagamento da taxa de R$ 40,00, evidenciando a falta de preparo para coisas simples – o que diremos sobre coisas importantes como a sustentabilidade do negócio.
A falha no site da TelexFree
Comprando os seus vaporwares que eles afirmam ser produtos, o usuário precisa gerar um boleto para fazer o pagamento. Pois bem, esse boleto é online (como muitos e-commerces fazem) e gera não somente uma linha digitável, mas uma versão digital de um boleto impresso, totalmente editável, copiável, rastreável e – o pior – INDEXADO pelo Google.
A URL de geração de boleto do Banco do Brasil é sequencial e facilmente descoberta com pesquisas no Google (eu não vou expor a URL aqui nesse texto, por respeito aos milhões de consumidores que estão com seus dados desprotegidos). Que dados são expostos?
- Nome do consumidor
- Endereço (na maior parte das vezes completo)
- CEP, Cidade e Estado
- Valor pago (pode-se concluir qual pacote adquirido)
Pouco antes de ter suas atividades bloqueadas pela Justiça, a empresa fez alterações em seu painel de controle para implementar um captcha e o uso de CPF “para melhorar a segurança e evitar transferências ilegais”. Captcha e CPF? Depois de quase um ano de atividades eles se preocuparam em associar um CPF à conta de um usuário? E desde quando captcha é mecanismo de segurança? Não me admira tantas reclamações de “dinheiro que sumiu” no ReclameAqui e BOs criados.
Como a falha pode ser explorada?
Se algum desocupado mal intencionado quiser, pode criar um script para capturar os dados dos consumidores, incluindo o valor pago, para uso próprio. O layout respondido é o mesmo, não há limite de conexões e a geração de boletos é sequencial, ou seja, mais fácil que isso só “hello world”.
Como a falha poderia ter sido evitada?
O ID de geração de boleto poderia ser um hash ou acompanhado de um hash one-way. O PHP (usado para gerar os boletos) possui diversas funções online para geração de hashes, uma forma simples de segurar uma página com dados públicos porém sensíveis.
Outra proteção que poderia ter sido feita no servidor é evitar o acesso direto ao gerador de boletos. Caso esse documento não precisasse ter link enviado por e-mail, por exemplo, a geração poderia ser feita dentro da área autenticada ou, mesmo fora, permitir apenas acessos vindos do próprio site.
Além disso, e ainda muito mais básico, é o parâmetro no-index utilizado nas páginas dessa natureza. Gente, por favor, se você tem uma página com dados sensíveis e que precisam ser acessados sem uma sessão de autenticação antes, POR FAVOR, remova a indexação dessa página. Não é nada legal descobrir que seu nome aparece nos sites de busca numa página que exibe um boleto de serviços, com todos os dados da empresa que você está comprando, e incluindo os seus dados pessoais.
PS: Nem todo robô respeita o no-index, então, sempre use um hash para proteger esses dados.
UPDATE: 31 de Julho de 2013
Após este meu post ter sido anunciado na INFO, MeioBit e TecnoBlog, demorou apenas algumas horas para que a empresa – finalmente – tomasse alguma atitude. Agora não é mais possível acessar os boletos diretamente (embora eles ainda estejam disponíveis no cache do Google), mas a biblioteca que foi utilizada continua lá, firme e forte (quer dizer, vulnerável a SQL Injections).
Algumas considerações se fazem necessárias, tendo em vista comentários feitos pelos lesados pela empresa:
- A data impressa no boleto é exatamente a mesma que a página foi acessada. Por esse motivo, o boleto exibido aqui tem a data de 29/07 e na INFO de 30/07. Isso é uma característica do sistema que eles utilizaram, não houve manipulação de imagem nesse sentido;
- O fato de a empresa estar bloqueada para operar não torna automaticamente os seus sistemas indisponíveis. Para que isso ocorra, a empresa precisa indisponibilizá-los manualmente. Aparentemente, esqueceram desse;
- Os valores gerados no documento são fixos, porque assim estão no banco de dados da empresa. O sistema deles, pelo visto, não verifica se determinado boleto já foi pago para deixá-lo de exibir na web, ou sequer recalcula o valor do dólar. Mas ninguém esperava tantas verificações de uma pirâmide, não é mesmo?
- Por fim, ataques pessoais serão desconsiderados ou moderados. Esse texto cumpriu o seu papel. Fez com que a empresa tomasse uma atitude e deixasse de exibir os dados das pessoas. Ponto final.
