Wikipédia

Cross-site request forgery

O cross-site request forgery (CSRF ou XSRF), em português falsificação de solicitação entre sites, também conhecido como ataque de um clique (one-click attack) ou montagem de sessão (session riding), é um tipo de exploit malicioso de um website, no qual comandos não autorizados são transmitidos a partir de um usuário em quem a aplicação web confia.[1] Há muitos meios em que um site web malicioso pode transmitir tais comandos, tags de imagem especialmente criadas, formulários ocultos e XMLHttpRequests de JavaScript, por exemplo, podem funcionar sem a interação do usuário ou mesmo seu conhecimento. Diferente do cross-site scripting (XSS), que explora a confiança que um usuário tem para um site específico, o CSRF explora a confiança que um site tem no navegador de um usuário.

Antecedentes editar

As vulnerabilidades CSRF foram conhecidas e em alguns casos exploradas desde 2001.[2] Como é feita a partir do endereço IP do usuário, alguns registros do website podem não ter evidências do CSRF. As explorações são sub-notificadas, pelo menos publicamente, e a partir de 2007 [3] há poucos exemplos bem documentados. Cerca de 18 milhões de usuários da Companhia de Leilões eBay em Auction.co.kr na Coreia do Sul perderam as informações pessoais em fevereiro de 2008 [carece de fontes?]. Clientes de um banco no México foram atacados no início de 2008 com uma tag na imagem do e-mail. O link da tag da imagem mudou a entrada DNS para o banco em seu roteador ADSL para apontar para um site malicioso, representando o banco.[4]

Características e Exemplos editar

 
A página da National Vulnerability Database descrevendo um furo CSRF

O ataque funciona através da inclusão de um link ou script numa página que acede a um site no qual se sabe (ou se supõe) que o utilizador tenha sido autenticado.[5] Por exemplo, um usuário, Bob, pode estar a navegar num fórum de bate-papo onde outro usuário, Fred, postou uma mensagem. Suponha-se que Fred tenha criado um elemento da imagem HTML que faz referência a uma ação no site do banco de Bob (em vez de um arquivo de imagem), por exemplo,

<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=Fred">

Se o banco de Bob mantém a sua informação de autenticação num cookie, e se o cookie não expirou, então a tentativa do browser de Bob de carregar a imagem irá submeter o formulário de levantamento com o seu cookie, assim, autorizando uma transação sem a aprovação de Bob. A falsificação de solicitação entre sites é um ataque do tipo Confused deputy contra um navegador Web. O deputy no exemplo do banco é o navegador Web de Bob que é confundido para fazer mau uso da autoridade de Bob na direção de Fred.

As seguintes características são comuns ao CSRF:

  • Envolvem sites que dependem de uma identificação do usuário
  • Exploram a confiança do site nessa identificação
  • Iludem o navegador do usuário para o envio de solicitações HTTP para um site de destino
  • Envolvem solicitações HTTP que têm efeitos colaterais

Os riscos são as aplicações Web que executam ações com base na confiança e autenticação das entradas dos usuários, sem exigir que o usuário autorize a ação específica. Um usuário que é autenticado por um cookie guardado no navegador web do usuário, sem saber, pode enviar um pedido HTTP a um site que confia no usuário e, assim, fazer uma ação indesejada.

Ataques CSRF em tags de imagem muitas vezes são feitas a partir de fóruns na Internet, onde os usuários têm permissão para postar imagens, mas não JavaScript.

Limitações editar

Várias coisas têm que acontecer para que um cross-site request forgery tenha sucesso:

  1. O atacante deve ter como alvo tanto um site que não verifica o campo Referer do cabeçalho HTTP (que é comum) ou uma vítima com um bug no navegador ou plug-in que permite alterar o campo Referer (o que é raro).
  2. O atacante deve encontrar uma submissão do formulário no local de destino, ou uma URL que tem efeitos colaterais, que faz algo (por exemplo, transferências de dinheiro, ou mudanças de endereço da vítima e-mail ou senha).
  3. O atacante deve determinar os valores corretos para todos os formulários ou entradas URL; se qualquer um deles são obrigados a serem os valores de autenticação secreta ou identificações que o atacante não pode adivinhar, o ataque irá falhar.
  4. O atacante deve atrair a vítima para uma página Web com código malicioso enquanto a vítima está conectada ao site de destino.

Note-se que o ataque é cego, ou seja, o invasor não pode ver o que o site-alvo envia de volta à vítima, em resposta aos pedidos forjados, a menos que ele explore um cross-site scripting ou outro bug no site do alvo. Da mesma forma, o atacante só pode ter como alvo algum link ou apresentar qualquer formulário que surge após o pedido inicial forjado, se essas relações subsequentes ou formulários são igualmente previsíveis. (Alvos múltiplos podem ser simulados, incluindo várias imagens em uma página, ou usando JavaScript para introduzir um atraso entre os cliques). Dadas essas limitações, um atacante pode ter dificuldade em encontrar registros das vítimas ou envios de formulários atacáveis. Por outro lado, as tentativas de ataque são fáceis de montar e invisíveis às vítimas, e projetistas de aplicações são menos familiarizados e preparados para ataques CSRF do que para, digamos, ataques de adivinhação de senha dicionarizada.

Gravidade editar

De acordo com o Departamento Americano de Segurança Nacional o CSRF é a vulnerabilidade mais perigosa classificada em 909° nos bugs de software mais perigosos já encontrados, tornando esta vulnerabilidade mais perigosa do que a maioria dos buffer overflows. Outras foram emitidas para as vulnerabilidades que resultam em CSRF na execução remota de código com privilégios de root,[6] assim como uma vulnerabilidade que pode comprometer um certificado root, que irá enfraquecer completamente uma infra-estrutura de chave pública.[7]

Pedidos de login forjados editar

Um atacante pode forjar um pedido de registro da vítima em um site-alvo usando as credenciais do atacante, que é conhecido como login CSRF. O login CSRF faz diversos novos ataques possíveis, por exemplo, um atacante pode depois de fazer o login no site com as suas credenciais legítimas e ver as informações privadas, como histórico de atividades que foi armazenado na conta.[8] O ataque foi demonstrado contra o YouTube.[9]

Outras abordagens para o CSRF editar

Além disso, embora geralmente descrito como um tipo estático de ataque, o CSRF também pode ser dinamicamente construído como parte de uma carga útil de um ataque de cross-site scripting, como demonstrado pela Samy ou construídos em tempo real a partir de informações de sessões vazadas através de conteúdo externo e enviado para um destino como um URL maliciosa. Tokens CSRF também poderiam ser enviados a um cliente por um atacante, devido à fixação da sessão ou outras vulnerabilidades, ou adivinhada através de um ataque de força bruta,[10] processado em uma página maliciosa que gera milhares de solicitações com falha. A classe de ataque "Dynamic CSRF", ou carga usada por um cliente para um sessão específica falsificada, foi descrita[11] em 2009 por Nathan Hamiel e Shawn Moyer na BlackHat Briefings,[12] embora a taxonomia ainda tenha que ganhar aprovação mais ampla.

Prevenção editar

Os usuários individuais da Web que usam versões não modificadas dos navegadores mais populares podem fazer relativamente pouco para evitar cross-site request forgery. Logout dos sites e evitar o recurso "lembrar-me" podem mitigar o risco de CSRF; não exibir imagens externas ou não clicar em links de spam ou não confiáveis nos e-mails também pode ajudar.

Extensões do navegador, como RequestPolicy (para Mozilla Firefox) pode evitar CSRF, proporcionando uma política padrão para negar pedidos de cross-site. No entanto, isso pode interferir significativamente com o funcionamento normal de muitos sites. A extensão CsFire (também para o Firefox) podem mitigar o impacto do CSRF com menos impacto sobre a navegação normal, removendo informações de autenticação de solicitações cross-site.

Web sites têm várias contra-medidas para o CSRF disponíveis:

  • Exigindo um segredo, específico do token do usuário em todas os formulários de submissões e o efeito colateral das URLs impedem o CSRF; o site do invasor não pode colocar o token direto nas suas alegações [5]
  • Exigir que o cliente forneça dados de autenticação na solicitação HTTP mesmo se utilizado para realizar qualquer operação com implicações de segurança (transferência de dinheiro, etc)
  • Limitar o tempo de vida de cookies da sessão
  • Verificando o cabeçalho HTTP Referer
  • Assegurando que não há nenhum arquivo clientaccesspolicy.xml para a concessão de acesso não intencional aos controles Silverlight[13]
  • Assegurando que não há nenhum arquivo crossdomain.xml concedendo acesso não intencional de vídeos em Flash [14]
  • Verificando que o cabeçalho da solicitação contém um X-Requested-With. Usado por Ruby on Rails (anterior ao v2.0) e Django (anterior ao v1.2.5). Essa proteção tem sido comprovada como não segura[15] sob uma combinação de plugins do navegador e redirecionamento, o que pode permitir que um invasor forneça cabeçalhos HTTP personalizados em uma solicitação para qualquer site, portanto, permite um pedido forjado.

Uma variante desta abordagem é duplicar o envio de cookies para usuários que usam JavaScript. Se um cookie de autenticação é lido usando JavaScript antes que a postagem seja feita, as regras de cross-domain JavaScript mais rigorosas (e mais corretas) serão aplicadas. Se o servidor requer solicitações para conter o valor do cookie de autenticação no corpo de pedidos POST ou a URL perigosa solicita o GET, a solicitação deve ter vindo de um domínio confiável, já que outros domínios são incapazes de ler os cookies do domínio confiável. Verificando o cabeçalho HTTP Referer para ver se a solicitação é proveniente de uma página autorizada é comumente usado para dispositivos de rede incorporada, porque não aumenta os requisitos de memória. No entanto, um pedido que omite o cabeçalho Referer mediante a emissão de pedidos de FTP ou URLs HTTPS. Esta rigorosa validação Referer pode causar problemas com navegadores ou proxies que omitem o cabeçalho Referer por razões de privacidade. Além disso, as versões antigas do Flash (antes de 9.0.18) permitem que o Flash malicioso gere pedidos GET ou POST com cabeçalhos arbitrários de solicitação HTTP usando injeção CRLF. Vulnerabilidades CRLF são semelhantes a injeção em um cliente que pode ser usado para falsificar a referência de uma solicitação http.

Para evitar falsificação de pedidos de login, os sites podem usar essas contramedidas do CSRF no processo de login, antes mesmo que o usuário esteja logado.

Sites com as necessidades de segurança especialmente rigorosas, como bancos, muitas vezes efetuam logoff dos usuários (por exemplo) depois de 15 minutos de inatividade.

Utilizar o modo de uso especificado do HTTP para GET e POST, em que solicitações GET nunca terão um efeito permanente, é uma boa prática, mas não é suficiente para evitar CSRF. Atacantes podem escrever JavaScript ou ActionScript que invisivelmente envia um formulário POST para o domínio de destino. No entanto, filtrando GETs inesperados, impede-se que alguns ataques particulares, tais como ataques de cross-site usando URLs de imagens maliciosas ou endereços de link e de cross-site vazem informações através de elementos do <script> (JavaScript hijacking); mas também evita (não-relacionadas à segurança) problemas agressivos com web crawlers e link prefetching. [5]

Referências

  1. ↑ Ristic, Ivan (2005). Apache Security. [S.l.]: O'Reilly Media. p. 280. ISBN 0-596-00724-8 
  2. ↑ Burns, Jesse (2005). «Cross Site Request Forgery: An Introduction To A Common Web Weakness» (PDF). Information Security Partners, LLC. Consultado em 6 de outubro de 2011 
  3. ↑ Christey, Steve and Martin, Robert A. (22 de maio de 2007). «Vulnerability Type Distributions in CVE (version 1.1)». MITRE Corporation. Consultado em 7 de junho de 2008 
  4. ↑ «List of incidents for which Attack Method is Cross Site Request Forgery (CSRF)». Web Application Security Consortium. Fevereiro de 2008. Consultado em 4 de julho de 2008 
  5. ↑ a b c Shiflett, Chris (13 de dezembro de 2004). «Security Corner: Cross-Site Request Forgeries». php|architect (via shiflett.org). Consultado em 3 de julho de 2008 
  6. ↑ «US-CERT Vulnerability Note VU#584089 - cPanel XSRF vulnerabilities». www.kb.cert.org. Consultado em 14 de maio de 2012 
  7. ↑ «US-CERT Vulnerability Note VU#264385 - OpenCA allows Cross site request forgery (XSRF)». www.kb.cert.org. Consultado em 14 de maio de 2012 
  8. ↑ Adam Barth, Collin Jackson, and John C. Mitchell, Robust Defenses for Cross-Site Request Forgery, Proceedings of the 15th ACM Conference on Computer and Communications Security, ACM 2007
  9. ↑ Jeremiah Grossman, Google YouTube crossdomain security flaw
  10. ↑ «Hacking CSRF Tokens using CSS History Hack». securethoughts.com. Consultado em 14 de maio de 2012  Texto " SecureThoughts.com" ignorado (ajuda)
  11. ↑ «Security Fix - Weaponizing Web 2.0». voices.washingtonpost.com. Consultado em 14 de maio de 2012 
  12. ↑ «Dynamic Cross-Site Request Forgery (CSRF)». web.archive.org. Consultado em 14 de maio de 2012. Arquivado do original em 5 de janeiro de 2010 
  13. ↑ «Making a Service Available Across Domain Boundaries». msdn.microsoft.com. Consultado em 14 de maio de 2012 
  14. ↑ Cross-domain policy file usage recommendations for Flash Player
  15. ↑ «Django». docs.djangoproject.com. Consultado em 14 de maio de 2012. Arquivado do original em 7 de julho de 2012  Texto "Django documentation" ignorado (ajuda); Texto "Django 1.2.5 release notes" ignorado (ajuda)

Ligações externas editar

Obtida de "https://pt.wikipedia.org/w/index.php?title=Cross-site_request_forgery&oldid=64058112"