--- id: CP-053 slug: csrf-pedido-forjado-entre-sites lang: pt title: "O CSRF: a ação forçada à sua revelia" description: Um site armadilhado ou uma mensagem pode fazer o seu navegador agir por si num serviço onde tem sessão iniciada. Eis o mecanismo e as defesas. canonical_url: https://startbrain.io/cyberpedia/pt/articles/csrf-pedido-forjado-entre-sites/ markdown_url: https://startbrain.io/cyberpedia/pt/articles/csrf-pedido-forjado-entre-sites.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: "Brain, «O CSRF: a ação forçada à sua revelia», Cyberpedia, 2026. https://startbrain.io/cyberpedia/pt/articles/csrf-pedido-forjado-entre-sites/ (CC BY 4.0)" wing: 1 theme: understand_hacking reflex: cr-018 schema: G3 updated: "2026-11-03" translations: pt: https://startbrain.io/cyberpedia/pt/articles/csrf-pedido-forjado-entre-sites/ fr: https://startbrain.io/cyberpedia/fr/articles/csrf-requete-forcee-inter-sites/ en: https://startbrain.io/cyberpedia/en/articles/csrf-cross-site-request-forgery/ de: https://startbrain.io/cyberpedia/de/articles/csrf-websiteuebergreifende-anfragefaelschung/ es: https://startbrain.io/cyberpedia/es/articles/csrf-falsificacion-peticiones-entre-sitios/ it: https://startbrain.io/cyberpedia/it/articles/csrf-richiesta-contraffatta-tra-siti/ nl: https://startbrain.io/cyberpedia/nl/articles/csrf-afgedwongen-verzoek-tussen-sites/ sources: - "n": 1 title: Cross Site Request Forgery (CSRF) | OWASP Foundation publisher: OWASP url: https://community.owasp.org/attacks/csrf accessed: "2026-11-03" - "n": 2 title: Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core publisher: Microsoft url: https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0 accessed: "2026-11-03" - "n": 3 title: Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html accessed: "2026-11-03" - "n": 4 title: SameSite | OWASP Foundation publisher: OWASP url: https://community.owasp.org/SameSite accessed: "2026-11-03" - "n": 5 title: "CWE - CWE-352: Cross-Site Request Forgery (5.0)" publisher: MITRE url: https://cwe.mitre.org/data/definitions/352.html accessed: "2026-11-03" --- # O CSRF: a ação forçada à sua revelia O CSRF (Cross-Site Request Forgery) é um ataque que obriga um utilizador a executar ações indesejadas numa aplicação web onde já está autenticado [1]. O atacante não precisa da palavra-passe da vítima: faz agir o navegador dela. Para um colaborador, o cenário típico é simples. Um webmail ou um site de um banco está aberto num separador. Uma ligação recebida por e-mail ou por mensagem instantânea leva a outra página, e essa página desencadeia, em segundo plano, um pedido ao serviço que continua com sessão iniciada [1]. ## Em 30 segundos - Onde acontece: na maioria dos serviços web sem proteção anti-CSRF, quando abre uma ligação ou uma página armadilhada no mesmo navegador [1]. - O que quer o atacante: provocar uma ação que altera alguma coisa, como uma transferência ou uma mudança de palavra-passe [1]. - O reflexo: terminar a sessão num serviço quando acaba de o utilizar [2]. - De onde vem a falha: da aplicação, não do utilizador [2]. ## Perguntas diretas ### O CSRF rouba a minha palavra-passe? Não, em si mesmo não. O ataque toma emprestadas a identidade e as permissões da vítima para realizar uma ação em nome dela [1]. Visa as ações que alteram o estado do serviço, como mudar o endereço de e-mail ou a palavra-passe, ou comprar algo. Obrigar a vítima a consultar dados não beneficia o atacante, porque é a vítima que recebe a resposta, não ele [1]. ### Porque é que o serviço obedece a um pedido que não fiz? Porque não consegue distingui-lo de um pedido legítimo. Na maioria dos sites, os pedidos do navegador incluem automaticamente as credenciais associadas ao site, como o cookie de sessão [1]. Se o utilizador está autenticado, o site não tem, por isso, forma de separar o pedido forjado do pedido real [1]. O CWE descreve a fraqueza assim: a aplicação não verifica, ou não consegue verificar, que um pedido foi fornecido voluntariamente pelo utilizador que o enviou [5]. ### Estou protegido se o serviço usar HTTPS? Não. Segundo a OWASP, o HTTPS por si só não protege do CSRF, embora continue a ser um pré-requisito para que as outras medidas sejam fiáveis [1]. ### O problema vem de mim ou da aplicação? Da aplicação. A Microsoft di-lo sem rodeios: as falhas CSRF são fundamentalmente um problema da aplicação web, não do utilizador final [2]. Os gestos do utilizador apenas limitam a exposição: terminar a sessão quando acaba e limpar regularmente os cookies do navegador [2]. ## Na pele do atacante O atacante começa por identificar um pedido que altera algo num serviço e depois fabrica um endereço ou um script que o reproduz com os seus próprios valores. A OWASP dá o exemplo de um banco fictício: o pedido legítimo transfere 100 dólares para um beneficiário, e o atacante substitui o beneficiário por si próprio, aumentando o montante [1]. Falta fazer a vítima carregar esse pedido enquanto tem a sessão iniciada. São citados dois métodos: um e-mail não solicitado com conteúdo HTML, ou uma armadilha colocada em páginas que a vítima possa visitar enquanto usa o seu serviço em linha [1]. O ataque pode também ficar armazenado no próprio site vulnerável, por exemplo num campo que aceita HTML. Torna-se então mais provável: a vítima consulta mais facilmente uma página do site do que uma página qualquer da Internet, e nele tem forçosamente a sessão já iniciada [1]. ## O que vê no ecrã Muitas vezes, nada. A ligação armadilhada pode estar disfarçada de ligação comum, com um texto como «ver as minhas fotografias». Pode também assumir a forma de uma falsa imagem de tamanho nulo: se estiver num e-mail, a vítima não vê nada, mas o navegador envia na mesma o pedido, sem qualquer sinal visual de que a operação teve lugar [1]. ```text Ilustração neutralizada, não é um endereço real. Ligação disfarçada: texto apresentado «Ver as minhas fotografias», endereço escondido hxxp://banque[.]exemple[.]invalid/virement?dest=[conta do atacante]&montant=[elevado] Variante: imagem invisível num e-mail, carregada sem clique. ``` Se o serviço esperar um pedido do tipo POST, o atacante pode alojar no seu site um formulário com campos escondidos. A vítima julga que ele faz outra coisa e clica, ou então um script envia-o automaticamente quando a página carrega [1]. Nos dois casos, a página apresentada é banal e a ação decorre noutro sítio. ## Por baixo do capô O mecanismo assenta num comportamento normal dos navegadores. Estes guardam os cookies emitidos por uma aplicação, incluindo os cookies de sessão dos utilizadores autenticados, e enviam todos os cookies de um domínio em cada pedido, seja qual for a forma como esse pedido nasceu no navegador [2]. Os cookies não são os únicos em causa: as autenticações do tipo Basic e Digest também são vulneráveis, porque o navegador reenvia automaticamente as credenciais até ao fim da sessão [2]. Várias ideias de defesa não funcionam, segundo a OWASP [1]: - um cookie secreto, já que todos os cookies são enviados com cada pedido; - aceitar apenas pedidos POST, já que um formulário escondido basta para forjar um; - as transações em várias etapas, desde que o atacante consiga prever cada etapa; - a verificação isolada do cabeçalho Referer, porque pode ser falsificado e, por vezes, está ausente por razões de privacidade. As proteções recomendadas, do lado da aplicação, são as seguintes. - Verificar primeiro se a framework já oferece proteção CSRF e usá-la. Caso contrário, acrescentar tokens anti-CSRF a todos os pedidos que alteram o estado e validá-los no servidor [3]. Sem token, o atacante não consegue fabricar um pedido válido [3]. - Para software sem estado, usar um cookie de dupla submissão, de preferência assinado [3]. - Definir o atributo SameSite nos cookies de sessão [3]. Com o valor strict, o navegador não envia o cookie nos pedidos entre sites, mesmo ao seguir uma ligação comum. Com lax, envia-o para uma ligação seguida a partir de outro site, mas retém-no nos métodos expostos ao CSRF, como o POST [4]. Com none, não é oferecida nenhuma proteção [4]. - Controlar a origem com os cabeçalhos padrão, nomeadamente Sec-Fetch-Site, suportado por todos os grandes navegadores desde março de 2023 [3]. - Não usar pedidos GET para operações que alteram o estado [3]. Estas medidas têm limites. O SameSite=Lax deixa passar os pedidos GET de navegação de nível superior: um ponto de acesso que altere o estado por GET continua vulnerável [2]. Os navegadores antigos podem não aplicar o SameSite [2]. E uma falha XSS pode contornar todas as proteções anti-CSRF; o verme Samy, por exemplo, usou um XMLHttpRequest para obter o token CSRF e forjar pedidos [1][3]. O comportamento por omissão do SameSite varia: em dezembro de 2024, lax era o valor por omissão do Chrome, do Edge e do Opera, mas de nenhuma versão do Firefox nem do Safari, daí o conselho de o definir explicitamente [4]. ## Autópsias ### 2008: o exploit do uTorrent A OWASP cita, como exemplo real de ataque CSRF contra uma aplicação que funciona por pedidos GET, um exploit dirigido ao uTorrent, de 2008. Foi usado em grande escala para descarregar software malicioso [1]. A fonte não diz mais: nem o número de vítimas, nem o modo de difusão. ### Falhas catalogadas pelo CWE (identificadores de 2004 a 2009) O CWE-352 apresenta uma lista escolhida de exemplos observados, que não é exaustiva [5]. Vários assentam num simples URL numa etiqueta img: o CVE-2004-1703 e o CVE-2004-1995 permitem acrescentar contas de utilizador, o CVE-2004-1842 permite obter privilégios de administrador [5]. Outros afetam a própria administração: o CVE-2009-3520 permite alterar a palavra-passe do administrador, e o CVE-2009-3759 permite mudar palavras-passe ou desligar uma máquina virtual a partir de uma interface web [5]. ## Fontes 1. OWASP, «Cross Site Request Forgery (CSRF) | OWASP Foundation». https://community.owasp.org/attacks/csrf (consultado em 3 de novembro de 2026) 2. Microsoft, «Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core». https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0 (consultado em 3 de novembro de 2026) 3. OWASP, «Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html (consultado em 3 de novembro de 2026) 4. OWASP, «SameSite | OWASP Foundation». https://community.owasp.org/SameSite (consultado em 3 de novembro de 2026) 5. MITRE, «CWE - CWE-352: Cross-Site Request Forgery (5.0)». https://cwe.mitre.org/data/definitions/352.html (consultado em 3 de novembro de 2026) --- Fonte original: Cyberpedia, a enciclopédia pública de cibersegurança e IA publicada pela Brain. Versão canónica: https://startbrain.io/cyberpedia/pt/articles/csrf-pedido-forjado-entre-sites/ Pode reutilizar livremente este texto sob a licença CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), desde que cite «Brain, Cyberpedia» com uma ligação para o endereço acima.