Lição aprendida com o Flogão: usuários são frequentemente hackeados. Por culpa deles e por culpa sua! Parte 1
Nesta semana o Twitter foi “abalado” por dois ataques em sequência que resultaram em várias contas de usuários famosos sendo invadidas. O primeiro ataque veio de um site de pishing, que se fazia passar pelo Twitter e solicitava senhas de usuários. O segundo aconteceu devido a uma falha de segurança em uma ferramenta administrativa do site – e o pior, de acordo com o invasor, o acesso a essa ferramenta foi obtido quebrando a senha de uma funcionária do suporte do Twitter.
Esses acontecimentos me inspiraram a abordar o tema segurança de contas de usuários. Apesar da afirmação feita no título do post parecer óbvia demais (e é mesmo), frequentemente desenvolvedores de sites sociais, fóruns e serviços semelhantes baixam a guarda em relação à segurança das contas de usuários e acabam aprendendo a duras penas, a custa de muitos usuários invadidos, a como lidar com isso. Como desenvolvedor e supervisor de suporte no Flogão fui um desses que inicialmente baixou a guarda, e como era de se esperar nós no Flogão tivemos que confrontar o problema da pior maneira: com usuários desesperados berrando nos canais de suporte, querendo o acesso (e o conteúdo) restabelecido em suas contas.
A seguir relato alguns dos problemas que enfrentamos e como contorná-los. Vou dividir o post em duas partes (a segunda publicarei amanhã), e mesmo que elas tenham ficado um pouco longas, acho que vale a pena serem lidas.
Os “causos” que rolaram no Twitter nesta semana são bem ricos para este assunto pois cobrem as principais, digamos, modalidades de falhas que afetam as contas de usuários: no código, nas ferramentas de suporte, da equipe de suporte e por fim, dos próprios usuários.
Falhas no código
Problemas no código-fonte do site são a falha mais grave e que geralmente afeta mais usuários, caso venham a ser descobertas por alguém mal intencionado. E existe muita gente assim, com bastante tempo disponível, procurando por elas. No Flogão, tivemos um problema muito sério relacionado ao armazenamento e acesso à criptografia das senhas que nos fez perder o Natal no primeiro ano de funcionamento do site, além de alguns problemas recorrentes ao longo dos tempos com os cookies que forneciam as credencias de acesso e a validação dos usuários em contextos e servidores diferentes .
Embora não seja possível (e nem é a minha intenção) relacionar nem mesmo as principais falhas que um programador pode cometer neste “quesito”, a lição aprendida foi a de que todo zelo, pesquisa e, principalmente, revisão do código que se puder fazer, poderá ser insuficiente. Por isso, meu conselho um tanto óbvio é para você desenvolva o site sem pressa e com cuidado, pesquise muito no Google sobre as melhores práticas de autenticação, validação de dados, acesso e recuperação de informações de usuários.
A ênfase em “revisão do código” é importante, porque demanda que o desenvolvedor saia de sua “zona de conforto”, e isso não é fácil para ninguém, em área de trabalho nenhuma. Recebi muitas ligações em madrugadas do meu sócio (que monitorava os servidores e a atividade no site) dizendo que uma conta de usuário importante havia sido invadida e que podia haver uma falha na segurança. Na maioria das vezes ele estava sendo apenas chato, mas em algumas tinha razão. Com todas as horas que passava pesquisando, revisando e tentando melhorar o código, a minha reação inicial a essas ligações era de perplexidade: dizia que era impossível haver uma falha, que devia ser culpa no usuário (e quase sempre era mesmo), e tentava voltar a dormir prometendo revisar tudo novamente no dia seguinte. Por mais que a maioria dessas revisões tenham acontecido em vão, eu preciso admitir que elas foram uma parte vital do processo de aperfeiçoamento do sistema, e algumas delas geraram correções que evitaram potenciais catástrofes. Portanto, engulam o orgulho quando receberem uma notificação de falha, saiam de sua zona de conforto e revisem muito os seus códigos, mesmo quando não for solicitado. Sempre é possível melhorar.
Falhas nas ferramentas de suporte
Brechas nas ferramentas de suporte são potencialmente tão destrutivas quanto falhas no código-fonte, e possibilitarem invasões prejudiciais para a imagem do site e dos usuários. Barack Obama, Britney Spears e outros usuários famosos do Twitter que foram invadidos nesta semana que o digam.
Todo site que tem usuários cadastrados precisa ter essas ferramentas para auxiliar os colaboradores que não entendem lhufas de programação a atenderem bem as principais demandas dos clientes. Quanto mais completas suas ferramentas, melhor será o suporte aos usuários. E, como ilustrado acima, é preciso zelar por elas também. A lista de práticas de segurança mínimas inclui colocar essas ferramentas num subdomínio dedicado, de nome não óbvio, de preferência numa porta não-padrão, e principalmente não acessível a sistemas de busca. Bloqueie via firewall ou aplicação qualquer acesso feito de IPs ou hostnames desconhecidos – e se todos os que acessam essas ferramentas trabalham num único local (o escritório da empresa), melhor ainda, você pode limitar os acessos ao IP da rede da empresa.
Mais importante que isso é estabelecer com bastante critério diferentes níveis de acesso a funcionalidades das ferramentas de suporte. Desenvolva-as de modo que um colaborador só tenha acesso às informações estritamente necessárias para realizar seu trabalho, e nunca, nunca mesmo, dê a qualquer colaborador poderes para editar ou postar informações nas páginas dos usuários, nem efetuar alterações diretas nas senhas ou emails (ao invés disso, por exemplo, pode haver uma funcionalidade que acione o envio por parte do sistema de um email com uma nova senha diretamente para o usuário).
Você pode e deve ter uma “senha de super usuário” que possibilita essas alterações diretamente na ferramenta de suporte (para ser usado, por exemplo, em caso de usuários invadidos), mas deve deixar que somente o desenvolvedor, ou o dono do negócio, ou alguém de igual importância e com muita noção sobre o que está fazendo e sobre como proteger o próprio computador de invasões. Porque se alguém mal intencionado tiver acesso a essa senha, meu amigo, a casa vai cair!
No próximo capítulo…
A segunda parte deste post, relatando falhas da equipe de suporte e falhas dos usuários, pode ser lida aqui.
Pingback: Lição aprendida com o Flogão: usuários são frequentemente hackeados. Por culpa deles e por culpa sua! Parte 2 | Sana inside