Questão de Segurança da Informação — Ataques a Aplicações Web (XSS, CSRF, SQL Injection etc.) — FCC 2025

Server-Side Request Forgery (SSRF) e sua mitigação

Gabarito: letra B. O SSRF (Server-Side Request Forgery) é um ataque em que o invasor induz o servidor a fazer requisições HTTP para destinos não previstos — como serviços internos, metadados de nuvem ou endereços de rede privada — e a mitigação mais adequada entre as opções é a aplicação de whitelisting de URLs, que restringe os destinos que a aplicação pode acessar. As demais alternativas tratam de controles de segurança válidos, mas voltados a outras classes de ameaça (autenticação, injeção SQL, autorização e configuração de servidor), não ao SSRF.

O SSRF explora a confiança que a aplicação deposita no próprio servidor: quando uma funcionalidade precisa buscar um recurso a partir de uma URL fornecida pelo usuário (por exemplo, importar uma imagem, validar um webhook ou consultar um serviço externo), o atacante manipula esse parâmetro para apontar para endereços internos — como http://localhost, http://169.254.169.254 (metadados da nuvem) ou IPs de rede privada — e o servidor, agindo em nome da aplicação, executa a requisição. O perigo está em o servidor ter privilégios de rede que o cliente não tem: ele pode alcançar serviços internos, ler credenciais ou executar ações em sistemas que deveriam estar isolados.

A defesa central contra o SSRF é controlar o destino das requisições que a aplicação pode fazer. O whitelisting de URLs (ou allowlist) é a prática mais direta: define-se uma lista explícita de domínios, IPs ou faixas de rede que a aplicação está autorizada a acessar, e qualquer requisição fora dessa lista é bloqueada. Isso impede que o atacante redirecione o servidor para endereços internos ou para serviços de metadados. Medidas complementares incluem: validar e sanitizar a entrada do usuário, bloquear IPs privados e de loopback, usar resolução de DNS controlada, aplicar autenticação em serviços internos e segmentar a rede para que o servidor de aplicação não tenha acesso direto a recursos sensíveis.

É importante distinguir o SSRF de outros ataques web com os quais ele costuma ser confundido. O SQL Injection explora a construção de consultas ao banco de dados; o XSS injeta scripts que rodam no navegador da vítima; o CSRF força o navegador autenticado da vítima a executar ações; o SSRF, por sua vez, faz o servidor realizar requisições a destinos não autorizados. Cada um exige uma defesa específica: prepared statements para SQL, sanitização de saída para XSS, tokens anti-CSRF para CSRF e controle de destinos (whitelisting) para SSRF. A banca explora exatamente essa confusão: oferece defesas corretas para outros ataques e espera que o candidato identifique qual delas se aplica ao SSRF.

A pegadinha desta questão está em apresentar controles de segurança legítimos e amplamente recomendados — MFA, prepared statements, RBAC e hardening — que são excelentes práticas, mas que não atacam a causa raiz do SSRF. O candidato que não domina a mecânica do ataque tende a escolher uma defesa genérica de "boa segurança" em vez da medida específica. Guarde o par ataque-defesa: SSRF se combate restringindo o que o servidor pode acessar, e é exatamente nesse critério que as alternativas se separam.

Alternativa A — ❌ Incorreta

A Autenticação Multifator (MFA) adiciona uma camada extra de verificação de identidade do usuário, dificultando o acesso não autorizado a contas. Ela é eficaz contra ataques de roubo de credenciais, força bruta e phishing, mas não impede que o servidor faça requisições a destinos não autorizados. No SSRF, o atacante não precisa de credenciais: ele explora a funcionalidade legítima da aplicação para fazer o servidor acessar recursos internos. O MFA protege a autenticação, não o controle de destinos das requisições do servidor.

Alternativa B — ✅ Correta ⟵ GABARITO

A aplicação de whitelisting de URLs é a prática mais adequada para mitigar SSRF. Ao definir uma lista explícita de destinos permitidos, a aplicação bloqueia requisições para endereços internos, IPs privados, loopback ou serviços de metadados — exatamente o vetor explorado pelo SSRF. Essa medida ataca a causa raiz do ataque: o controle do que o servidor pode acessar. É a defesa direta e específica para essa vulnerabilidade.

Alternativa C — ❌ Incorreta

Prepared statements e Object-Relational Mapping (ORM) são técnicas de prevenção contra SQL Injection, pois separam os dados dos comandos SQL, impedindo que entradas maliciosas alterem a estrutura da consulta. No SSRF, não há injeção de comandos SQL: o atacante manipula uma URL ou parâmetro de requisição para redirecionar o servidor. Essas técnicas não têm efeito sobre o controle de destinos das requisições HTTP.

Alternativa D — ❌ Incorreta

O controle de acesso baseado em funções (RBAC) gerencia as permissões dos usuários dentro do sistema, definindo o que cada perfil pode fazer. Ele é essencial para o princípio do menor privilégio e para evitar acesso não autorizado a funcionalidades, mas não controla as requisições que o servidor faz em nome da aplicação. No SSRF, o atacante explora a funcionalidade legítima do servidor, e o RBAC não interfere nesse fluxo.

Alternativa E — ❌ Incorreta

Hardening é o processo de endurecer a configuração de sistemas e servidores, removendo serviços desnecessários, aplicando patches, fechando portas e ajustando permissões. É uma prática importante de segurança de base, mas não é específica para SSRF. O hardening reduz a superfície de ataque em geral, mas não impede que uma aplicação vulnerável faça requisições a destinos não autorizados — para isso, é necessário o controle de destinos, como o whitelisting.

Gabarito: letra B — aplicação de whitelisting de URLs é a prática mais adequada para mitigar ataques SSRF.