Essenciais de Segurança Web: SSRF, CSRF e CORS Explicados

No cenário web moderno, a segurança não é apenas uma funcionalidade — é uma fundação. À medida que as aplicações se tornam mais interconectadas, entender as nuances de como as requisições são tratadas em diferentes origens e servidores é crucial para qualquer desenvolvedor.

Hoje, vamos mergulhar em três conceitos críticos que todo desenvolvedor web deve dominar: SSRF, CSRF e CORS. Embora possam parecer uma sopa de letrinhas, eles representam as linhas de frente da segurança de aplicações web.

1. SSRF (Server-Side Request Forgery)

SSRF é uma vulnerabilidade onde um atacante pode forçar uma aplicação do lado do servidor a fazer requisições HTTP para um domínio arbitrário de escolha do atacante.

Como Funciona

Imagine uma aplicação web que recebe uma URL como entrada (ex: para buscar uma foto de perfil ou pré-visualizar um link) e então faz uma requisição para essa URL a partir do servidor. Se a aplicação não validar corretamente essa URL, um atacante pode fornecer um endereço IP interno ou um endereço de loopback (127.0.0.1).

O servidor, agindo como um proxy, pode então buscar dados sensíveis de serviços internos que não estão expostos à internet pública, tais como:

• Metadados de Nuvem: Acessar 169.254.169.254 na AWS/GCP para recuperar credenciais IAM.
• Painéis de Admin Internos: Acessar ferramentas internas como Jenkins ou dashboards de Kubernetes.
• Escaneamento de Portas: Descobrir outros serviços rodando na rede interna.

Prevenção

• Allowlisting: Permita apenas requisições para uma lista predefinida de domínios confiáveis.
• Validação de Entrada: Garanta que a URL use protocolos permitidos (ex: apenas https://) e não aponte para faixas de IP interno.
• Segregação de Rede: Garanta que o servidor web tenha acesso restrito a recursos internos.

2. CSRF (Cross-Site Request Forgery)

CSRF é um ataque que engana o navegador de uma vítima para realizar uma ação indesejada em outro site onde a vítima está autenticada no momento.

Como Funciona

Este ataque explora o fato de que os navegadores incluem automaticamente credenciais de ambiente — como cookies de sessão — em cada requisição para um domínio.

1. Um usuário faz login em bank.com.
2. O usuário visita um site malicioso evil.com em outra aba.
3. O site evil.com contém um formulário oculto que envia uma requisição POST para bank.com/transfer?amount=1000&to=attacker.
4. O navegador envia a requisição junto com o cookie de sessão do usuário para o bank.com.
5. O bank.com vê uma sessão válida e processa a transferência.

Prevenção

• Tokens Anti-CSRF: Inclua um token único, secreto e imprevisível em cada requisição que altere o estado. O servidor verifica este token antes do processamento.
• Cookies SameSite: Defina o atributo SameSite nos cookies como Strict ou Lax para evitar que sejam enviados em requisições entre sites.
• Headers Personalizados: Para requisições AJAX, exija um header personalizado (ex: X-Requested-With) que não possa ser definido por um formulário HTML padrão.

3. CORS (Cross-Origin Resource Sharing)

Diferente de SSRF e CSRF, o CORS não é uma vulnerabilidade em si, mas um mecanismo de segurança. É uma forma de os servidores dizerem ao navegador: “Tudo bem que esta origem externa específica acesse meus recursos.”

Por Que Existe

Por padrão, os navegadores aplicam a Política de Mesma Origem (SOP), que impede que um script em um site leia dados de outro site. Isso evita que o evil.com leia seus e-mails no gmail.com.

O CORS permite que os servidores relaxem essa política com segurança. Quando um web app faz uma requisição cross-origin, o navegador envia um header Origin. O servidor responde com Access-Control-Allow-Origin.

Erros Comuns de Configuração

• Origem Wildcard (*): Permitir todas as origens. Embora seja aceitável para APIs públicas, é perigoso se combinado com Access-Control-Allow-Credentials: true.
• Refletir a Origem: Definir dinamicamente a origem permitida com base no header Origin sem validação. Isso efetivamente ignora completamente a SOP.

Melhores Práticas

• Seja Específico: Permita apenas os domínios específicos que precisam de acesso.
• Evite Credenciais se possível: Se sua API não precisa de cookies ou headers de autorização, não os permita.
• Use um Middleware de Segurança: Use bibliotecas bem testadas para lidar com a configuração de CORS em vez de gerenciar os headers manualmente.

Resumo Comparativo

Entender esses três pilares da segurança web é essencial para construir aplicações modernas e robustas. Ao implementar estratégias de defesa em profundidade, você pode proteger tanto a infraestrutura interna do seu servidor quanto os dados privados dos seus usuários.

Mantenha-se seguro e boa codificação!