Vamos de Cross Site Request Forgery? | SideChannel

Introdução

Usuários podem possuir a prática de navegar pela Internet utilizando apenas um perfil do seu navegador de preferência. Cada perfil contém várias informações sobre seu usuário, como por exemplo: cookies de sessão, credenciais salvas, bookmarks para os seus sites preferidos, extensões instaladas e configurações personalizadas, entre outros dados. Através deste mesmo perfil, pode-se abrir abas ou novas janelas e, por exemplo, manter-se conectado com suas redes sociais, acessar sites do seu histórico ou simplesmente continuar sua sessão de streaming de música. Em suma, ao usar um único perfil, toda a sua navegação pela Internet encontra-se no mesmo ‘contexto’.

O uso de um mesmo contexto proporciona o aumento da superfície de ataque do usuário, pois o mesmo pode estar autenticado ao mesmo tempo em seu banco, no e-mail corporativo, no e-mail pessoal e em sites de e-commerce; tendo, assim, todas estas informações centralizadas no mesmo perfil. Desta forma, as chances do comprometimento dos seus dados são ampliadas. Através de uma extensão maliciosa, de uma aba adicional para um site não tão “conhecido” ou de um e-mail duvidoso, um atacante pode explorar um problema de segurança nos websites que a vítima esteja acessando, resultando, por exemplo, no roubo de informações, já que o uso de um único perfil de navegação viabiliza a centralização dos dados do usuário.

Toda essa locomoção de informações de perfil é extremamente fácil nos dias de hoje. Podemos analisar o navegador Google Chrome por exemplo, que possibilita associar os dados do perfil com um endereço de e-mail. Assim, ao utilizar o Google Chrome, de forma autenticada, em qualquer computador, seus dados de navegação (credenciais, preferências, etc.) podem ser restaurados facilmente. Será que os usuários, ao restaurar tais dados num novo computador, avaliam se o mesmo já está comprometido ou se ele se encontra em um rede vulnerável de alto risco?

Com a amplificação do trabalho home office (vale ressaltar o artigo de Carlos Cabral: “Cibersegurança no home office em tempos de coronavírus”) é cada vez mais comum o uso do mesmo computador para o manejo de informações da vida pessoal junto a dados corporativos, concentrando assim, na maioria dos casos, todo esse volume de dados em um único perfil de navegação, o que acaba colocando ainda mais em risco as informações sensíveis do usuário.

São vários os caminhos que um atacante pode percorrer para roubar os dados do perfil de navegação de um usuário. Aqui, trataremos de uma vulnerabilidade antiga, comumente chamada de CSRF (ou Cross Site Request Forgery) cujo ataque é furtivo, de exploração simples e que ainda pode causar alto impacto. O CSRF representa o uso de uma funcionalidade de um site de forma falsificada, pois o atacante irá enganar e induzir o usuário a realizar uma ação legítima porém sem o seu consentimento. Este tipo de investida explora a confiança do site na sessão do usuário, presente no seu perfil de navegação.

Segundo um levantamento realizado pela OWASP em 2013, o CSRF encontrava-se na lista das 10 vulnerabilidades mais comuns em aplicações Web. Esse ranking ressalta a consciência em segurança da informação em websites, sendo a sua versão mais recente a de 2017.

A partir da minha experiência na área, posso afirmar que essa vulnerabilidade é facilmente encontrada em um grande número de aplicações, com o agravante de que, em alguns casos, as empresas aplicam correções incorretas ou ineficientes para evitar investidas através desse vetor de ataque.

Podemos citar o caso da Netflix, quando em outubro de 2006 foi divulgada a notícia de que a empresa havia resolvido a vulnerabilidade que permitia a atacantes alterar o endereço dos usuários e até mesmo roubar as suas contas através do CSRF. Na época, a Netflix possuía 5 milhões de assinantes operando através seu website de aluguel de DVDs. Pouca gente sabe, mas a história da Netflix começa bem antes dela ficar famosa com o serviço de streaming. Em 1997, na Califórnia, a empresa surgiu como locadora física de filmes, e revolucionou o mercado, primeiramente com o serviço de aluguel pelo website: com entregadores que tanto levavam, quanto buscavam os filmes nos endereços cadastrados. Dois anos depois, a empresa surpreendeu novamente ao cobrar uma taxa fixa mensal para seus clientes, permitindo que eles encomendassem e recebessem em casa quantos filmes desejassem. Foi assim que a Netflix transformou seus clientes em assinantes, aumentando não apenas o número de cadastros em seu website, mas sobretudo o volume de acessos, atraindo também os atacantes que buscavam dados de usuários em larga escala. Por tudo isso, a empresa mostrou-se preocupada com as falhas de segurança em seu website e rapidamente solucionou os problemas de segurança reportados pelo pesquisador Dave Ferguson, e que poderiam levar ao roubo dos dados de seus milhões de usuários.

Objetivo

O objetivo deste blogpost é trazer informações sobre o CSRF de forma direta, de modo a apresentar uma visão geral sobre os possíveis impactos, e os cenários de ataque. Irei discorrer sobre as soluções implementadas com as quais me deparei, e que infelizmente, não protegem contra esse tipo de investida. Finalmente, apresentarei as recomendações ideias para as aplicações web em torno do CSRF, também conhecido como sea surf, XRSF, session riding ou one-click attack.

Impacto

A exploração deste problema de segurança pode se resumir em um atacante induzindo o usuário a realizar uma ação sem o seu consentimento. O grau de impacto do ataque irá depender do nível de privilégio que o usuário possui no website alvo, bem como da funcionalidade escolhida para a investida.

Sendo assim, vamos supor o seguinte cenário:

Estamos lidando com uma aplicação de carteira digital, ou seja, uma aplicação financeira com movimentações de dinheiro e gerenciamento de cartões de crédito. Vamos chamá-la de CateiraDeCouroDigital. Essa aplicação possui, no mínimo, três vulnerabilidades já conhecidas, sendo elas: uma enumeração de usuário (o que torna possível coletar os e-mails dos usuários) na página de autenticação; a possibilidade de alteração de dados críticos sem o fornecimento de um fator de autenticação; e o CSRF.

O primeiro passo do atacante é identificar um usuário válido no site através da enumeração de usuários. Em seguida, o atacante dispara um e-mail para a vítima enumerada anteriormente. Esse e-mail vai conter um link, para uma aplicação de sua posse, ilustrando uma promoção qualquer. Quando a vítima acessar tal página, será acionada uma chamada à funcionalidade do CateiraDeCouroDigital (onde o usuário legítimo está devidamente autenticado em uma aba no mesmo perfil do site acessado). A chamada em questão tem a capacidade de alterar o endereço de e-mail da vítima (neste caso de [email protected] para [email protected]). Como a aplicação não possui nenhuma solicitação de um fator de autenticação para a troca de dados cadastrais (a senha de acesso, por exemplo) fica fácil para o invasor realizar essa chamada falsificada em nome do usuário legítimo. A imagem a seguir ilustra a investida descrita anteriormente:

Figura 1 — Diagrama para exemplificação de um CSRF

Em resumo, um usuário legítimo encontra-se autenticado em sua aplicação financeira em uma aba qualquer do seu navegador. Ele também possui outra aba para um site de notícias e mais uma para o site malicioso. Assim, como observado no passo 3 da Figura1, ao acessar o site malicioso, a chamada para a funcionalidade de alteração de e-mail é efetuada. A carteira digital permite a troca de senha de autenticação e de operações transacionais através de uma funcionalidade de “esqueci a senha”. Essa funcionalidade envia o link do reset de senha para o e-mail recém alterado, de posse do atacante. Dessa forma, o invasor realiza o roubo da credencial da plataforma alvo, podendo efetuar danos financeiros com o acesso indevido.

O problema de segurança

Vamos levar em consideração um outro cenário:

Uma aplicação web chamada SiteOficial gerencia informações financeiras de uma grande instituição. Um usuário com permissão administrativa encontra-se devidamente autenticado e utiliza a funcionalidade de adição de novo usuário para um recém integrante do time. A Figura2 representa tal cenário e algumas informações sobre tal fluxo:

Figura 2 — Representação da aplicação e do fluxo de requisição e resposta do servidor

Quando a funcionalidade em questão é utilizada, uma requisição HTTP é disparada para o servidor da aplicação, onde o seu pedido é processado e executado com sucesso. A requisição ora mencionada poderá ser visualizada na Figura3 com mais detalhes. Vale ressaltar que tal cenário também possui uma comunicação através de canal seguro com o uso de HTTPS (o famoso cadeado verde ao lado do endereço do site no navegador). Neste ambiente, a estação do usuário e a rede onde está conectado não estão comprometidos por agentes maliciosos.

Os parâmetros utilizados para a adição de um novo usuário no sistema em questão são dados de nome, usuário, tipo de usuário, senha e confirmação de senha.

Figura 3 — Requisição HTTP da funcionalidade ‘adicionar novo usuário’

A intenção do atacante é a de realizar uma chamada falsificada de requisição mostrada previamente através de um outro site, induzindo o navegador de sua vítima a executar a requisição de forma não autorizada e o sem consentimento do usuário. Na Figura4 vê-se o trecho de código que o atacante construiu em sua página web maliciosa, onde ele define os valores dos parâmetros:

Figura 4 — trecho de código para uma página maliciosa. É apenas um dos exemplos que podem ser construídos por atacantes.

Uma vez que a página maliciosa é acessada no mesmo perfil de browser em que a vítima esteja autenticada na aplicação SiteOficial, a página irá submeter automaticamente o formulário ilustrado na Figura4 para a aplicação alvo. Assim, a função para adicionar um novo usuário será executada sem que a vítima perceba. Isto ocorre porque o navegador da vítima irá inserir automaticamente o cookie de sessão, “SesseionId” (demonstrado na Figuras 2 e 3), para a aplicação vulnerável, SiteOficial.

Agora que o atacante possui uma conta com privilégios administrativos, ele pode expandir o impacto do seu ataque a partir das funcionalidades disponibilizadas pela aplicação.

Utilizando uma funcionalidade chamada Generate CSRF PoC do Burp Suite, que é uma ferramenta bastante comum no arsenal dos analistas de segurança da informação, pode-se facilmente gerar uma página maliciosa contendo o formulário para ser submetido a uma aplicação. A Figura5 demonstra como essa ferramenta pode criar a página em questão:

Figura 5 — Burp Suite proxy — geração de um CSRF PoC

A função em questão gera um trecho de código, conforme ilustrado anteriormente na Figura4, e com dois cliques é possível realizar o teste da vulnerabilidade descrito.

“Soluções” falhas

As empresas realizam algumas ações que não são efetivas para a correção do problema, como novos cookies chamados “Anti-CSRF”, o que não faz sentido, já que o ataque utiliza justamente os cookies da vítima para realizar uma determinada ação. Também tentam resolver a vulnerabilidade inserindo em sua aplicação múltiplas etapas para finalizar uma operação, porém isso também não protege contra o CSRF.

Então, para impedir que o atacante crie uma chamada falsificada de modo a obter êxito induzindo ações de outros usuários, deve-se adicionar um token secreto nas requisições efetuadas pela aplicação. Assim, um atacante, a priori, não terá sucesso ao submeter um formulário tal qual o da Figura4 sem esse token, já que ele não terá acesso ao valor do mesmo. Desse modo, a aplicação passará a enviar esse token nas requisições de alteração, criação ou remoção de algo relativamente crítico.

Entretanto, alguns problemas nesse modelo de correção podem ser encontrados em sites que utilizam tais tokens. Listamos a seguir, alguns deles:

O token secreto Anti-CSRF é apenas validado em requisições com o método POST, deixando vulnerável as requisições que usam chamadas para o método GET;
Quando o servidor não verifica o token, o mesmo pode ser omitido do formulário sob ataque;
O token não está atrelado à sessão da vítima e é simplesmente distribuído a partir de um global pool da aplicação, tornando possível ao atacante utilizar o seu token secreto para executar uma ação em uma outra conta;
A possibilidade de reuso desse token, deixando um valor fixo em todas as requisições;
A utilização de um token previsível.

Esses são apenas alguns exemplos de problemas nesse modelo de correção, já que o invasor sempre tentará subverter as validações impostas. Por isso, testes de consultoria em segurança nas aplicações são de extrema importância, tanto para a identificação das fragilidades, com o alerta devido para correções ineficientes, como para as análises direcionadas a apresentar soluções mais seguras para cada caso.

Recomendações

O recomendável é blindar o servidor da aplicação a não receber chamadas que não tenham sido originadas pelo usuário legítimo no contexto do site. Dentre as possíveis soluções para tal problema, deve-se utilizar tokens de uso único e não previsíveis, inseridos em campos hidden nos formulários HTML, que precisam ser validados no servidor da aplicação como forma de impor um desafio. Assim, cada requisição, além de validar o cookie de sessão, deve também verificar se o token do desafio foi recebido corretamente na submissão do formulário. É importante que a cada requisição realizada, um novo token seja fornecido pelo servidor. Esse mecanismo é denominado de Per-Page Token. Este token é de uso único e sempre deve ser verificado em todas as operações da aplicação. A Figura6 demonstra o exemplo de um token em um formulário HTML.

Figura 6 — token no HTML em uma operação da aplicação

Vale ressaltar que o ataque é do tipo blind, onde o invasor não será capaz de obter uma confirmação do sucesso da investida (de forma imediata), como por exemplo uma reposta da operação, conforme o acesso a documentos de um outro domínio é restrito pela política do same-origin policy. Assim, devido à essa política, o atacante não conseguirá obter os valores dos tokens secretos que estão associados ao usuário e à sua sessão.

Uma outra camada de defesa é o uso do atributo sameSite dos cookies. Essa configuração é responsável por fazer o navegador decidir se as informações do cookie de sessão serão enviadas para as requisições que estão vindo de outras aplicações fora do seu domínio. Os valores possíveis para esse atributo são: Lax, Strict ou None.

O uso do valor Strict nesse atributo faz com que o navegador evite o envio do cookie caso uma chamada falsificada tente ser realizada (fig.7).

Figura 7 — Servidor enviando o cookie com os atributos necessários para proteger CSRF

Entretanto, vale salientar que essa implementação de sameSite no cookie, apesar de estar presente nos navegadores mais utilizados, pode não estar presente em todos os browsers, conforme apresentado neste recurso. Logo, em alguns casos, o mecanismo será inútil caso a vítima esteja navegando em um browser incompatível com o atributo.

Uma outra uma alternativa é a implementação de um campo customizado no cabeçalho da requisição HTTP, como um “X-CSRF-Header-field” (fig.8).

Figura 8 — Campo customizado no cabeçalho HTTP de uma requisição

Esse tipo de defesa tem o apoio do same-origin policy para restringir que outros sites não realizem a inclusão de campo de cabeçalho customizado na chamada falsificada, trabalhando perfeitamente para as requisições AJAX ou de API (visto na maioria das aplicações hoje em dia). Para a proteção de documentos do tipo formulário HTML, como demonstrado no cenário do SiteOficial, utilize os tokens mencionados do primeiro parágrafo dessa seção de Recomendações.

Esses são exemplos de recomendações ideias para a tratativa do problema de segurança contra o CSRF e dependerão do modo como se está construindo a aplicação. Por isso é importante realizar a segurança em camadas, para que elas se adequem ao cenário de desenvolvimento. Outras proteções podem ser encontrados nessa “lista”.

Conclusão

Por fim, além do que já foi citado em todo esse texto, reforçamos que a implementação de diversas camadas de segurança é sempre importante. Um atacante motivado e com tempo, sempre irá buscar meios de subversão nas proteções aplicadas.

Recomendamos sempre seguir as boas práticas de segurança, avaliar o seu risco e diminuir a sua superfície de ataque ao máximo. Retomando as observações relatadas no início desse blogpost, como medida de segurança inicial, e bastante simples, a fim de evitar um impacto maior devido a uma falha de CSRF, ressaltamos aos usuários a importância da separação de perfis de navegação. É importante, ao menos, que se separe o perfil profissional, do perfil pessoal. Podendo-se também criar demais perfis: um apenas para pesquisas, outro para compras online, etc. Além, é claro, de estar sempre atento ao que é instalado e acessado em seu dispositivo.

Gostaria de ressaltar que neste artigo estamos tratando de um problema de segurança de aplicações web bastante antigo, mas que ainda hoje causa impactos negativos em suas vítimas. Existem diversas outras técnicas correlacionadas com o CSRF, porém o objetivo deste blogpost limita-se a trazer uma visão geral apenas desta vulnerabilidade.

Com a evolução de desenvolvimento de software e o aparecimento de diversos frameworks, que visam otimizar a construção de aplicações web, é bastante comum tais recursos prometerem sanar inúmeros problemas de segurança, sejam eles novos ou antigos. Contudo, lembramos que esses recursos são construídos através do fator humano, o que pode acabar apresentando novos problemas ou até mesmo sugerindo correções indevidas para tais problemas, visto que qualquer pessoa está factível ao erro.

Dado o ritmo acelerado com que nossa geração desenvolve novos produtos digitais, torna-se cada vez mais essencial a construção de websites sem vulnerabilidades conhecidas, como a de CSRF.

Para os que constroem: lembrem-se de possuir os requisitos de segurança somados aos requisitos operacionais de uma aplicação.

E para os que acessam: avaliem o uso de perfis de navegação diferentes, tenham cuidado ao entrar em sites desconhecidos, estando sempre cautelosos antes de inserir o seu cartão de crédito em qualquer aplicação.