Como funciona o ataque cross site request forgery?
Clickjacking
q
O ataque clickjacking, introduzido por Hansen e Grossman (2008), consiste em induzir a vítima a clicar em objetos de uma página que estão sobrepostos, invisivelmente, por elementos de uma aplicação web alvo. Desse modo, quando o usuário tenta clicar no objeto visível, na realidade, ele interage com a página transparente que está carregada por cima das demais. Isso pode ser feito por meio de um objeto iframe especificado com opacidade zero e com profundidade, definida pelo atributo z-index, maior que a da página visível. Esta, por sua vez, caso não seja controlada pelo atacante, deve ser carregada em outro iframe, com z-index menor. Sem isso, criar o frame superior implica alterar o documento original, o que é possível somente com código injetado, devido à política de mesma origem.
Nesse contexto, imagine que a página carregada no iframe superior pertença a uma aplicação web, na qual a vítima se encontra autenticada, em outra janela do navegador. Caso o clique, na camada invisível, ocorra em um botão de submissão de formulário, por exemplo, uma requisição POST é efetuada, contendo o identificador de sessão do usuário. A aplicação web não é capaz de diferenciá-la de uma solicitação legítima e, assim, a processa normalmente e retorna a resposta esperada. Note que esse ataque é bastante similar a um cross-site request forgery, diferindo apenas no fato de não poder ser auto- matizado. Isso, porém, não deve ser visto como um fator limitante, pois diversos ataques avançados são possíveis, graças a resultados recentemente obtidos (Stone, 2010).
Um exemplo real e relativamente recente de clickjacking afetou o Twitter, fazendo com que os usuários enviassem a mensagem Don’t Click: http://tinyurl.com/amgzs6 (Mahemoff, 2009). Quando um seguidor clicava no link, acessava uma página contendo um único botão com o título Don’t Click. Devido à curiosidade, este também era clicado, mas o item que de fato recebia o evento consistia no botão para envio de mensagem do Twitter, que era carre- gado em um iframe invisível e alinhado. Este definia como “src” o valor http://twitter.com/ home?status=Don’t Click: http://tinyurl.com/amgzs6, o que abria o Twitter com a mensagem misteriosa, pronta para ser enviada. O código HTML da página maliciosa empregada no ataque está ilustrado na Figura 4.14 (Balduzzi et al., 2010), e o processo de sobreposição e alinhamento, na Figura 4.15.
Te st e d e I nv as ão d e A pl ic aç õe s W eb <iframe style={
width:550px; height:228px; top:-170px; left:-400px; position:absolute; z-index:2; opacity:0;
filter:alpha(opacity=0); } scrolling= “no” src=”http://twitter.com/home?status=Don’t Click: http://tinyurl.com/amgzs6”> </iframe> <button style={
width:120px; top:10px; left:10px; position:absolute; z-index:1; }>
Don’t Click </button>
É importante observar, no código HTML da Figura 4.14, que Cascading Style Sheets (CSS) é
empregado, para posicionar o iframe e o botão, de maneira alinhada. Note que os atri- butos top e left do primeiro contêm valores negativos, em um esquema de posicionamento absoluto, o que faz com que a localização do canto superior esquerdo do iframe seja acima e à esquerda do canto correspondente da janela do navegador. Além disso, os índices de profundidade são definidos de modo que o botão fique para trás da página do Twitter, enquanto que a opacidade igual a zero torna o frame totalmente transparente. Opacity e
filter são utilizados concomitantemente por questões de compatibilidade com o Firefox e o
Internet Explorer, respectivamente.
Note que, nesse cenário, a adição de um token anti-CSRF não resolveria o problema, pois ele seria carregado juntamente com a página e submetido com a requisição, que sempre é efetuada manualmente pelo usuário, embora de maneira involuntária. Isso ilustra bem o fato de que a proteção contra cross-site request forgery, baseada em token individual, pode alternativamente ser quebrada por clickjacking, caso a aplicação não seja vulnerável a
Figura 4.14 Código HTML da página utilizada no ataque de clickjacking contra o Twitter. CSS Mecanismo simples utilizado para configurar a aparência de documentos web, que permite, dentre outras coisas, escolher fontes, posicionar objetos e definir as cores dos diversos elementos da página.
Figura 4.15
Clickjacking contra o Twitter.
Ca pí tu lo 4 - T es te d o g er en ci am en to d e s es sõ es
cross-site scripting. Para isso, porém, deve ser possível ao atacante preencher os campos do formulário, como no caso do Twitter, em que a tarefa é realizada por meio de valores passados na URL.
Como esse método não funciona, em muitos casos, outras técnicas devem ser consideradas para viabilização do ataque.
q
Um grande avanço consiste no uso das funcionalidades disponibilizadas pelos nave- gadores para arrastar objetos e soltá-los nos lugares desejados em substituição às operações de copiar e colar (Stone, 2010). Isso permite, dentre outras coisas, selecionar palavras, presentes no documento, e arrastá-las para dentro de um campo textual, de modo a preenchê-lo. Empregando a API drag-and-drop, padronizada em HTML5,
pode-se definir os dados, no início da operação de arrastamento, que devem ser copiados quando o mouse é liberado.
Uma característica chave desse mecanismo é que ele não se sujeita à política de mesma origem, permitindo, na maioria dos navegadores, que dados sejam arrastados entre páginas de domínios diferentes, sem restrições (Stone, 2010).
A justificativa para esse comportamento fundamenta-se na impossibilidade de tais eventos serem iniciados, programaticamente, por scripts sendo executados no navegador web. Em outras palavras, toda operação de arrastamento deve ser realizada deliberadamente pelo usuário, eliminando, portanto, a aplicabilidade da supracitada política.
Os passos seguintes resumem a técnica descrita por Stone (2010) para efetivação do ataque:
1. A vítima é induzida a arrastar um objeto visível de um ponto A a um ponto B da tela.
2. Quando a operação de arrastamento é iniciada, um script define o texto que deve ser copiado para o campo de formulário destino, o qual não fica visível para o usuário.
3. No momento em que a pessoa solta o objeto, o dado desejado é copiado para o campo alvo.
4. O processo deve ser orquestrado de modo que todos os campos necessários sejam preenchidos.
Para uma melhor compreensão do clickjacking e das evoluções recentes que sofreu, considere a aplicação DVWA, ilustrada na Figura 4.16. A página apresentada tem o objetivo de permitir a troca de senha, mas sem solicitar o valor anterior ao usuário. Isso facilita a ocorrência de um ataque de cross-site request forgery, que é combatido, por meio de um mecanismo baseado em tokens anti-CSRF, incluído na versão original do software, para o presente exemplo. Outra modificação realizada visa permitir a submissão do formulário via método POST, além do GET suportado originalmente.
API
Application Programming Interface. Especifica a interface de um conjunto de rotinas, descrevendo, para cada uma delas, o nome, os parâmetros de chamada, o tipo do retorno e a ação realizada. Figura 4.16 Aplicação DVWA modificada, para incluir token anti-CSRF.
Te st e d e I nv as ão d e A pl ic aç õe s W eb
Considerando que a aplicação não seja vulnerável a cross-site scripting, o ataque clickjacking deve ser empregado, para explorar o problema de cross-site request forgery. Com esse objetivo, a vítima, uma vez autenticada no DVWA, deve ser induzida a acessar uma página do atacante, como a apresentada na Figura 4.17. O disfarce utilizado, nesse cenário, consiste em um jogo de perguntas, no qual o usuário deve arrastar elementos da primeira para a segunda coluna.
Observe que a disposição dos elementos na coluna de respostas é muito similar à dos campos da aplicação alvo. Evidentemente, isso não é obra do acaso, mas, sim, resultado de um desenho cuidadoso, para que ocorra o alinhamento dos objetos, quando sobrepostos. Como o DVWA deve receber o evento de liberação do botão do mouse, é necessário que seja carregado no iframe superior. Porém, este não pode cobrir toda a área visível da tela, senão o evento que sinaliza o início do arrastamento não é recebido pela aplicação debaixo dele. Desse modo, a área que deve ser coberta corresponde somente aos dois campos de resposta mais o botão, conforme pode ser visualizado na Figura 4.18.
Note que a parte exibida do DVWA, na sobreposição, fica originalmente no meio da página, embora ocupe o canto superior do iframe. Isso implica que o conteúdo precisou ser
posicionado dentro do recorte, de modo a se obter o alinhamento dos elementos. Mas como isso é possível? Sabe-se que um script carregado a partir do site malicioso não tem per- missão para manipular o documento dentro do iframe, devido à política de mesma origem. Porém, como o iframe em si é um objeto oriundo do mesmo domínio, ele, sim, pode ser posicionado, na página de perguntas. Embora isso seja um passo em direção à solução, ainda não é suficiente para atender a demanda, pois um iframe maior precisaria ser definido, o que cobriria outras regiões da tela e impediria a correta captura de eventos. O truque, então, consiste em definir uma seção do documento HTML, por meio do marcador <div>, que cubra exatamente a área desejada. O posicionamento e o tamanho são obtidos
Figura 4.17 Aplicação visível do ataque clickjacking. Figura 4.18 Sobreposição da aplicação de per- guntas pelo DVWA.
Ca pí tu lo 4 - T es te d o g er en ci am en to d e s es sõ es
por meio de uma folha de estilo, cujo atributo overflow deve ser definido com o valor hidden, para que o conteúdo que extravase a região especificada não seja exibido. Dentro dessa divisão, define-se um iframe invisível, no qual a aplicação DVWA é carregada, com tamanho suficiente para a região de interesse ser visualizada, sem cortes, e posicionado de modo que os campos das duas aplicações fiquem alinhados. O código HTML correspondente a essa solução encontra-se documentado na Figura 4.19.
<div style=”position:absolute;left:190px;top:50px;height:100px; width:200px;overflow:hidden”>
<iframe id=”ifa” src=”http://dvwa.esr.rnp.br/vulnerabilities/ csrf/” style=”position:absolute;left:-300px;top:-208px; height:1000px;width:1000px;opacity:0.50” scrolling=”no”> </iframe> </div>
Falta, agora, descrever o mecanismo utilizado para injetar conteúdo nos campos textuais, por meio do arrastamento de objetos. Na Figura 4.18, os textos 1. RSA e 2. AES estão con- tidos em divisões separadas do documento HTML, especificadas pelo marcador <div>. Cada uma delas define o atributo draggable com o valor true, para que o objeto textual possa ser arrastado pelo usuário, além de código Javascript para tratamento dos eventos dragstart e dragend. O primeiro ocorre, no início do arrastamento, quando o valor a ser copiado deve ser definido, por meio do comando event.dataTransfer.setData(). Já o último acontece, ao final da operação, e deve resultar no preenchimento do campo de resposta, com o número esco- lhido. A Figura 4.20 ilustra o código HTML do primeiro elemento.
<div id=”f1” style=”position:absolute;left:10px;top:60px” draggable=”true” ondragstart=”event.dataTransfer.setData(‘text/plain’,’pwd’)” ondragend=”if (Y < 90) { document.forms[‘fd’].elements[‘r1’].value=1; } else { document.forms[‘fd’].elements[‘r2’].value=1;}”> 1. RSA </div> Figura 4.19 Código HTML para sobreposição de iframe, com posicio- namento e recorte.
Figura 4.20
Código HTML para sobreposição de iframe, com posicio- namento e recorte.
Te st e d e I nv as ão d e A pl ic aç õe s W eb
q
Uma maneira de evitar o ataque clickjacking, introduzida pela Microsoft, consiste na utilização do cabeçalho HTTP X-FRAME-OPTIONS, que indica ao navegador web em que condições uma dada página pode ser carregada em um frame. Um valor DENY proíbe completamente que isso aconteça, enquanto que um valor SAMEORIGIN permite o carregamento, desde que o contexto de navegação de mais alto nível seja exatamente o mesmo que o do conteúdo, para o qual a diretiva X-FRAME-OPTIONS foi definida (Rydstedt et al., 2010).
Uma desvantagem do método, que pode ser citada, resume-se na necessidade de ter de especificar o cabeçalho para todas as páginas da aplicação, impactando com isso o processo de desenvolvimento.
q
Outra técnica, chamada de frame busting, verifica, por meio de scripts, se a página está sendo carregada em um frame e, em caso positivo, redireciona o objeto window de mais alto nível, para ela própria.
O código que realiza essa tarefa, normalmente, é composto por um comando condicional e uma contramedida, como o ilustrado abaixo (Rydstedt, 2010):
if (top.location != location) top.location = self.location;
O código apresentado, embora comumente utilizado, pode ser quebrado por meio do atri- buto sandbox do iframe, que desabilita Javascript, e por diversos outros métodos (Rydstedt, 2010; Kuppan, 2010), como o tratamento do evento onBeforeUnload, disparado antes de uma página ser descarregada. Como as técnicas para quebrar frame busting consistem em evitar que o código Javascript seja executado, a estratégia de proteção deve ser invertida. Assim, em vez de tomar uma ação, quando a página é carregada em um frame, deve-se, por padrão, exibir uma página em branco e somente mostrar o documento original, caso o código de proteção não esteja executando no contexto de um frame.
Seguindo a ideia acima, a Figura 4.21 ilustra uma das soluções mais eficazes de frame busting, proposta por Rydstedt (2010). Note que, por meio de uma folha de estilo, a pro- priedade display é empregada para determinar que a página não deve gerar uma caixa CSS e, assim, não deve ser exibida. Caso Javascript possa ser executado, o script verifica se o documento HTML está sendo carregado na janela de mais alto nível. Em caso positivo, a propriedade display é alterada para o valor block, que gera uma caixa rodeada por quebras de linha, causando a exibição da página escondida; se não, ela é aberta programaticamente na janela principal, por meio do código “top.location = self.location”. Finalmente, se Javascript estiver desabilitado, nenhum código é executado, deixando a página no estado inicial e seguro, em que nada é exibido.
<style> html {display:none;} </style> <script> if (self == top) { document.documentElement.style.display = “block”; } else {
Ca pí tu lo 4 - T es te d o g er en ci am en to d e s es sõ es top.location = self.location; } </script>
Considerando o princípio de defesa em camadas, convém utilizar, simultaneamente, o cabe- çalho HTTP X-FRAME-OPTIONS e o método de frame busting, com o objetivo de minimizar o risco de a aplicação ser explorada, por meio de clickjacking. Estratégias desse tipo são muito importantes, porque nunca é possível garantir, com certeza absoluta, que um dado controle é completamente eficaz. Desse modo, caso um deles falhe, o atacante ainda precisa superar os demais obstáculos inseridos na aplicação para conseguir alguma vantagem relevante.
q
Finalmente, para verificar se uma aplicação qualquer é vulnerável a clickjacking, basta tentar carregá-la em um iframe, conforme ilustrado no exemplo abaixo:
<iframe src=”http://dvwa.esr.rnp.br” sandbox></iframe>
Se o sistema não impedir que isso aconteça, é possível afirmar que ele é susceptível ao ataque.
Contramedidas
q
De modo a evitar defeitos de segurança no mecanismo de gerenciamento de sessões de uma aplicação web, os seguintes controles devem ser adotados (Stuttard e Pinto, 2007; Siles, 2011; Kolšek, 2007; Rydstedt, 2010):
1Não crie esquemas de gerenciamento de sessões próprios. Em vez disso, utilize os for- necidos pelas linguagens e arcabouços utilizados no desenvolvimento da aplicação.
1Certifique-se de que os identificadores de sessão utilizados possuem boa aleatorie- dade e comprimento mínimo adequado.
1Empregue o protocolo HTTPS durante toda a sessão de usuário.
1Utilize os atributos secure e HttpOnly, para todos os cookies definidos pela apli- cação, de modo a protegê-los durante a transmissão e contra-acessos de códigos no lado do cliente.
1Não utilize os atributos domain e path, para nenhum dos cookies definidos pela apli- cação. Isso faz com que, automaticamente, os valores mais restritivos sejam adotados.
1Crie domínios de nomes separados para as aplicações críticas e as menos relevantes, de modo que cookies de domínio não possam ser compartilhados.
1Nunca aceite identificadores de sessão definidos pelo usuário. Caso isso aconteça, envie resposta com um novo valor.
1Sempre que houver mudança no nível de acesso à aplicação, um novo identificador de sessão deve ser definido e o antigo, invalidado.
1Associe cada identificador de sessão, no momento da criação, a propriedades da conexão, como o endereço IP de origem, por exemplo. Verifique, nas requisições subsequentes, se tais propriedades não foram alteradas, o que poderia indicar um comprometimento.
1Em modelos de gerenciamento de sessão estrito, se possível, defina um identificador de sessão somente após a autenticação do usuário. O objetivo desse controle é difi- cultar ataques de fixação de sessão, obrigando o usuário malicioso a possuir creden- ciais válidas de acesso à aplicação.
Te st e d e I nv as ão d e A pl ic aç õe s W eb
q
1Encerre as sessões, automaticamente, após um determinado período de ociosidade e depois de transcorrido um tempo total máximo de uso.
1Quando o usuário se desconectar da aplicação, invalide o identificador de sessão associado a ele, no lado do servidor. Para isso, a função específica do arcabouço de gerenciamento de sessões empregado deve ser chamada.
1Não permita que um mesmo usuário estabeleça múltiplas sessões paralelas, visando impedir o compartilhamento de senhas e dificultar o acesso de usuários maliciosos.
1Adicione tokens anti-CSRF a todas as páginas, gerando-os em função da URL, do iden- tificador de sessão, do nome da conta do usuário e de um segredo conhecido apenas pelo sistema.
1Solicite que o usuário se reautentique, antes que operações críticas sejam realizadas. Desse modo, caso uma requisição seja feita automaticamente, como parte de um CSRF, a operação somente é finalizada com anuência humana.
1Utilize o método POST em vez de GET. Embora isso não seja, nem de longe, uma solução completa contra CSRF, dificulta um pouco a vida do atacante eventual.
1Não permita que o navegador armazene credenciais de acesso, para que não sejam enviadas automaticamente em um cross-site request forgery.
1Não utilize o mesmo navegador para acessar sistemas críticos e navegar na internet.
1Especifique o cabeçalho HTTP X-FRAME-OPTIONS para todas as páginas da aplicação.
1Empregue a técnica de frame busting, para evitar que a aplicação web seja carregada em um frame de uma página originária de outro site web.
Ca pí tu lo 4 - R ot ei ro d e A tiv id ad es