Duas vulnerabilidades com nomes parecidos e naturezas bem diferentes: o CSRF (Cross-Site Request Forgery) engana o navegador da vítima a fazer uma requisição que ela não pretendia; o SSRF (Server-Side Request Forgery) engana o servidor a fazer uma requisição que ele não deveria. Ambos exploram uma relação de confiança — o CSRF explora a confiança do site na sessão da vítima; o SSRF explora a confiança da rede interna no servidor. O SSRF, em particular, tornou-se uma das vulnerabilidades mais críticas da era da nuvem. Vamos aos dois. Pratique no DVWA e nos labs do PortSwigger.

O cookie que o navegador envia sozinho

Comece pelo CSRF. Lembre da aula Arquitetura web e HTTP: entendendo o terreno: seu navegador envia automaticamente o cookie de sessão em toda requisição a um site onde você está logado. O CSRF abusa disso: se um atacante consegue fazer o seu navegador enviar uma requisição a um site onde você está logado, essa requisição carrega seu cookie de sessão automaticamente — e o site a trata como legítima, vinda de você. O ataque clássico: você está logado no seu banco; o atacante te envia um link (ou uma página com uma imagem/formulário oculto) que dispara uma requisição ao banco — digamos, uma transferência. Seu navegador executa a requisição com sua sessão ativa, e o banco, vendo seu cookie válido, realiza a transferência. Você "autorizou" sem saber, porque seu navegador foi enganado a agir em seu nome.

Usar a sessão contra a vítima

O ponto do CSRF é que ele não rouba sua sessão — ele a usa contra você. O atacante não vê suas respostas nem seu cookie; ele apenas provoca uma ação. Por isso o CSRF mira ações com efeito colateral (transferir, mudar senha, alterar e-mail, fazer uma compra), não leitura de dados. A defesa é conceitualmente elegante: garantir que cada requisição sensível prove ter sido intencionalmente originada pela aplicação legítima, e não injetada de fora. O mecanismo padrão são os tokens anti-CSRF: a aplicação inclui, em cada formulário, um token secreto e imprevisível que o atacante não pode adivinhar; uma requisição sem o token correto é rejeitada. Como o atacante, ao forjar a requisição de fora, não conhece o token, seu ataque falha. Complementarmente, o atributo de cookie SameSite (que instrui o navegador a não enviar o cookie em requisições vindas de outros sites) mitiga o CSRF na origem, e é hoje uma defesa importante e cada vez mais padrão.

SSRF: o servidor requisita por você

Agora o SSRF, de natureza oposta e crescente importância. Aqui, o atacante faz o servidor realizar requisições em seu nome. Muitas aplicações têm funcionalidades que buscam recursos de URLs — carregar uma imagem de um endereço, importar dados de uma API, gerar um preview de um link. Se a aplicação permite que o usuário controle essa URL sem restrição, o atacante pode fazer o servidor requisitar qualquer coisa que o servidor alcança — inclusive recursos internos que o atacante, de fora, não alcançaria. O servidor vira um "procurador" involuntário do atacante, e sua posição privilegiada (dentro da rede) é o que torna o SSRF perigoso.

Por que o impacto do SSRF é enorme

O impacto do SSRF é enorme justamente porque o servidor tem acesso a coisas que o mundo externo não tem. Um atacante com SSRF pode: escanear e acessar a rede interna (fazer o servidor requisitar http://10.0.0.5 e outros hosts internos — um pivô sem comprometer nada); acessar serviços que só escutam localmente (http://localhost:porta, painéis administrativos internos); e — o cenário mais devastador na nuvem — acessar o metadata service do provedor. Provedores de nuvem (AWS, Azure, GCP) expõem, a partir de dentro das instâncias, um endpoint de metadados num endereço especial (o famoso 169.254.169.254) que frequentemente contém credenciais de acesso da instância. Um SSRF que faz o servidor requisitar esse endereço pode vazar as credenciais de nuvem, levando ao comprometimento da infraestrutura de nuvem inteira (uma cadeia que aprofundaremos na aula Segurança em nuvem II: a cadeia SSRF → IMDS → IAM → escalação). Foi assim que ocorreram alguns dos maiores vazamentos de nuvem da história. Por isso o SSRF ganhou entrada própria no OWASP Top 10.

Ambos abusam de uma relação de confiança

O que une CSRF e SSRF conceitualmente é o abuso de uma relação de confiança para forjar requisições. No CSRF, abusa-se da confiança do servidor no navegador autenticado da vítima. No SSRF, abusa-se da confiança da rede interna (e do metadata service) no servidor. Em ambos, um intermediário confiável (o navegador da vítima, o servidor) é manipulado a fazer uma requisição que beneficia o atacante. Reconhecer esse padrão — "quem confia em quem, e como forço o confiado a agir?" — é uma lente poderosa para toda a segurança web.

Tokens anti-CSRF e a defesa multicamada do SSRF

Do lado defensivo: contra CSRF, tokens anti-CSRF (a defesa central), cookies SameSite, e verificação de origem das requisições — e note que APIs stateless com tokens no cabeçalho (não em cookies automáticos) são naturalmente mais resistentes. Contra SSRF, a defesa é rigorosa e multicamada, porque o impacto é grave: validar e restringir as URLs que o servidor pode requisitar (idealmente uma allowlist de destinos permitidos, não uma blocklist — que é facilmente contornada); bloquear o acesso a redes internas e ao endereço de metadados a partir da aplicação; usar as versões protegidas do metadata service que os provedores de nuvem oferecem (o IMDSv2 da AWS, que exige um passo que o SSRF simples não consegue fazer — uma mitigação crucial); e segmentação de rede que limite o que o servidor alcança. A lição do SSRF, especialmente relevante na nuvem: o servidor é um insider privilegiado, e permitir que sua entrada controle o que ele requisita é entregar essa posição privilegiada ao atacante.

Fontes e leituras recomendadas

Exercícios

  1. Como o CSRF abusa do comportamento automático do navegador com cookies de sessão?

    ✓ Resposta:

    O navegador envia automaticamente o cookie de sessão em toda requisição a um site onde a vítima está logada. O CSRF faz o navegador da vítima disparar uma requisição a esse site (via link, imagem ou formulário oculto); a requisição carrega o cookie automaticamente, e o site a trata como legítima, vinda da vítima.

  2. Por que se diz que o CSRF "não rouba a sessão, mas a usa contra você", e que tipo de ação ele mira?

    ✓ Resposta:

    Porque o atacante não obtém o cookie nem vê as respostas — ele apenas provoca o navegador da vítima a executar uma ação usando a sessão já ativa. Por isso mira ações com efeito colateral (transferência, mudança de senha/e-mail, compra), não a leitura de dados.

  3. O que é o SSRF, e por que a posição do servidor na rede torna essa vulnerabilidade tão perigosa?

    ✓ Resposta:

    SSRF é fazer o servidor realizar requisições controladas pelo atacante (via funcionalidades que buscam URLs). É perigoso porque o servidor alcança recursos internos que o atacante externo não alcança — rede interna, serviços locais, endpoints de metadados —, tornando-o um procurador privilegiado do atacante.

  4. Explique o cenário de SSRF contra o metadata service da nuvem e por que ele é tão devastador.

    ✓ Resposta:

    Provedores de nuvem expõem, de dentro das instâncias, um endpoint de metadados (ex.: 169.254.169.254) que frequentemente contém credenciais de acesso da instância. Um SSRF que faz o servidor requisitar esse endereço vaza essas credenciais, permitindo comprometer a infraestrutura de nuvem inteira — daí ser devastador.

  5. Qual a defesa central contra CSRF e qual a abordagem recomendada (allowlist vs. blocklist) contra SSRF, e por quê?

    ✓ Resposta:

    Contra CSRF, a defesa central são os tokens anti-CSRF (secretos e imprevisíveis, que o atacante externo não conhece), somados a cookies SameSite. Contra SSRF, recomenda-se allowlist (lista de destinos permitidos) em vez de blocklist, porque blocklists são facilmente contornadas (encodings, redirecionamentos, endereços alternativos), enquanto uma allowlist restringe o servidor apenas aos destinos legítimos.