Há uns dias atrás eu li no Facebook um artigo assustador mas totalmente comum. O site é de relacionamentos e “perdeu” 42 milhões de senhas NÃO CRIPTOGRAFADAS. Isso, por si só, é muito chocante. Fiquei pensando na quantidade de sites em que eu uso a mesma senha (eu sei, eu sei… muito errado) e que se qualquer um deles for comprometido, meu acesso a vários sites está aberto.
Para usuários, as dicas do artigo (link abaixo) são claras e boas. Use um gerador de senhas para garantir que cada site tenha sua própria senha. O navegador Safari agora tem um gerador de senhas embutido e eu tenho usado isso – até que funciona bem. A outra dica importante é: nunca use a mesma senha do seu e-mail para outros sites. Isso é importante porque se alguém entrar no seu e-mail, pode ir para qualquer site c clicar em “esqueci a minha senha” e acessar a sua conta.
Dito tudo isso, me choca que o site do artigo tivesse 42 milhões de assinantes e tão pouca preocupação com segurança. 42 milhões é um número respeitável de assinantes e tenho que partir do pressuposto de que esse site não era “amador”.
O site deveria ter uma preocupação mínima com a proteção dos dados dele e dos assinantes. Mas veja bem: A senha era guardada no banco sem criptografia. O site não exigia senhas difíceis – das 42M, 1.9M eram 123456 (5%!!!) O site era vulnerável a ataques – o artigo não menciona que tipo, mas o banco inteiro vazou, então foi feio.
A gente vê esse problema com frequência aqui no Agility Tech Center. As vezes o problema é de fato que a aplicação foi mal escrita ou foi escrita há anos e reescrevê-la é uma empreitada imensa. As vezes a empresa que desenvolveu nem existe mais, e as vezes é software comprado e o dono do site não tem acesso ao código fonte.
Aqui no Agility Tech Center a gente trabalha com várias tecnologias interessantes, e uma delas é o Web Application Firewall. O uso deste equipamento teria ajudado um portal desses a se proteger. O papel deste elemento é ficar entre o usuário final e o servidor web do portal. Ele monitora o comportamento do usuário e garante que o usuário não está tentando nada fora do esperado. Ao forçar o usuário a se comportar de acordo com a expectativa da aplicação, coisas como SQL Injection, parameter tampering e outros ataques à aplicação. A informação continua exposta dentro do portal, mas como o WAF não deixa ela sair, o site está protegido.
A configuração desses equipamentos não é totalmente trivial, mas também não é de outro mundo. E dependendo do número de aplicações que precisam ser protegidas e do acesso que (não) se tem ao código fonte, WAF têm se tornado cada vez mais uma solução fantástica.
E para finalizar, a gente tem testado isso com o serviço de monitoramento da WhiteHat. A WhiteHat tenta hackear o site todo dia. Se ela encontrar um problema, ela reporta o problema para você poder consertar ou, se você tiver um WAF, ela mesmo pode entrar na configuração dele e ajustá-lo para proteger desse novo ataque. Muito legal e prático.