O Gmail possui uma vulnerabilidade que permite explorar ataque de XSRF na sua página de troca de senha.
O que é XSRF?
XSRF é a sigla para Cross Site Request Forgery. Esta técnica pode ser usada de várias formas e a vítima tem que estar autenticada na aplicação vulnerável.
Quando um usuário se autentica em uma aplicação web existe uma relação de confiança entre o usuário e a aplicação durante o período de tempo em que a sessão autenticada permanece ativa. Neste período a aplicação não solicita uma nova autenticação (usuário e senha) a cada função que o usuário acessa da aplicação. Existe aplicações que solicitam novamente a senha em algumas funções críticas, como é o caso de pagamentos de contas em aplicações de home banking. Mas a maioria das aplicações web autenticam o usuário apenas uma vez e confiam nesta autenticação até o fechamento do navegador ou a sessão cair por tempo de inatividade.
Para fazer um ataque de XSRF, o atacante tem que conhecer a aplicação alvo e identificar a url ou o formulário que realiza a função crítica, como por exemplo, aprovação de processo, enviar mensagem, confirmar uma pendencia importante, etc. O atacante estuda a função crítica, identifica o enderço das páginas e os parâmetros que são enviados. De posse destas informações, o atacante monta um link ou um código HTML que irá executar a função crítica estudada. Por exemplo, pode existir uma aplicação financeira que quando um usuário legítimo aprova um pagamento através de um botão, o botão na verdade ativa o endereço http://aplicacao/aprova_pagamento?id_conta=10.
Conhecendo o endereço, os parâmetros e a forma com uma função crítica é chamada, o atacante tem que fazer a vítima clicar no link enquanto ela está autenticada na aplicação. Existem várias formas de se conseguir isso:
* Gravar um script ou html numa aplicação vulnerável a Cross Site Scripting. Quando o usuário autenticado acessar o script ou html gravado irá processar e executar a função da aplicação sem saber;
* Se aplicação permitir a edição de figuras, o atacante poderá incluir uma figura que execute uma url;
* Colocar um link em outra aplicação e solicitar para um usuário autenticado clicar no link ou acessar uma página que tenha o script ou o link montado especialmente para o XSRF.
Quando o usuário estiver autenticado na aplicação e clicar em um link ou acessar um página que tenha o script ou html com ataque de XSRF irá executar a função até mesmo sem saber. No nosso exemplo a vítima poderá aprovar um pagamento sem intenção através da chamada a url http://aplicacao/aprova_pagamento?id_conta=10.
Qual o perigo?
Existe um risco muito grande principalmente em aplicações que usam o conceito web 2.0. Essas aplicações possuem conteúdo montado por usuários, compartilhamento de informações e grande interatividade com usuários. Aplicações corporativas com funções críticas também são alvos deste tipo de ataque.
Como se proteger?
Se proteger deste tipo de ataque não é tarefa fácil.
A aplicação pode usar controles de token temporários que ajudam a evitar este tipo de ataque. O token temporário seria gerado em uma página anterior e seria validado na página crítica. O token dificulta, mas não evita 100%. O atacante teria que automatizar o ataque desde o momento da geração do token, o que dificulta bastante, mas não é garatia total.
Outro controle a ser aplicado é o uso de captcha em funções críticas. Captcha são aquelas figuras que temos que ler e digitar para confirmar alguma página. O captcha além de dificultar o usa da página por robôs e programas, dificultaria o ataque de XSRF. Mais uma vez apenas dificulta, pois o atacante pode usar recursos de OCR para ler o captcha.
A redigitação da senha também pode ser usado para evitar o XSRF. Além de proteger a aplicação por descuito do usuário que deixa a sessão aberta e se ausenta da frente do computador, a redigitação da senha evita o XSRF pois não é possível automatizar o ataque sem conhecer a senha do usuário. O ponto negativo é que se existir a redigitação da senha em muitas funções de uma aplicação, isto pode torná-lo pouco funcional e produtiva para o usuário final.
O Caso do Gmail
No caso do Gmail, qualquer usuário que esteja autenticado e executar a url abaixo irá trocar a senha sem passar por captcha ou controle de token.
https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=senha_antiga&Passwd=123&PasswdAgain=123&p=&save=Save
O atacante poderia montar uma página autenticacao_falsa.html que solicite a senha antiga e troque a senha do Gmail da vítima. Como o Gmail não implemente nenhum token ou outro tipo de controle entre páginas, se ele estiver autenticado e abrir página_falsa, a senha poderá ser trocada indevidamente.
Referência: http://seclists.org/fulldisclosure/2009/Mar/0029.html