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

SSRF (Server-Side Request Forgery) e a prevenção pelo OWASP Top 10

Gabarito: letra C. A prevenção mais eficaz contra SSRF é restringir as URLs que o servidor pode acessar, criando uma lista positiva (allowlist) de destinos permitidos — exatamente o que a alternativa C descreve. Essa medida está alinhada às diretrizes do OWASP Top 10 de 2021, que classifica o SSRF como uma das principais vulnerabilidades de aplicações web (A10:2021).

O SSRF (Server-Side Request Forgery) é um ataque em que o invasor explora a funcionalidade do servidor para fazer requisições a recursos internos ou externos que não deveriam ser acessíveis. O servidor, ao processar uma URL fornecida pelo usuário, pode ser induzido a acessar endereços internos (como 127.0.0.1, serviços de nuvem, redes privadas) ou externos, permitindo ao atacante ler dados sensíveis, realizar port scanning ou até mesmo comprometer outros sistemas. A raiz do problema é a falta de validação e controle sobre as URLs que a aplicação pode acessar.

A principal defesa, portanto, é restringir o alcance das requisições do servidor. Isso é feito por meio de:

• Lista positiva (allowlist): definir explicitamente quais domínios, IPs ou faixas de IP são permitidos. Qualquer URL fora dessa lista é bloqueada.

• Validação de entrada: verificar se a URL fornecida pelo usuário corresponde a um formato esperado e não contém caracteres maliciosos.

• Controle de rede: usar firewalls e regras de roteamento para impedir que o servidor acesse redes internas ou serviços de metadados (como o endpoint 169.254.169.254 em nuvens).

• Desabilitar redirecionamentos: evitar que o servidor siga redirecionamentos para destinos não autorizados.

O OWASP Top 10 de 2021 inclui o SSRF como a categoria A10:2021 – Server-Side Request Forgery, e as recomendações de prevenção giram em torno do controle de acesso a URLs e da segmentação de rede. A alternativa C reflete diretamente essa recomendação: "criar uma lista positiva de URLs que podem ser acessadas a partir do servidor que hospeda a aplicação web potencial alvo de ataque, não permitindo o acesso a outras URLs".

As demais alternativas apresentam medidas que não têm relação com a prevenção de SSRF, sendo distratores que confundem o candidato com outros conceitos de segurança. Vamos analisar cada uma.

Alternativa A — ❌ Incorreta

Troca o protocolo: usar HTTP em vez de HTTPS aumenta a vulnerabilidade, pois expõe o tráfego a interceptação. O SSRF não explora vulnerabilidades do TLS 1.2; ele explora a falta de controle sobre as requisições do servidor. A alternativa confunde SSRF com ataques de downgrade de protocolo ou com falhas criptográficas (A02:2021).

Alternativa B — ❌ Incorreta

A navegação anônima do navegador apenas impede o salvamento de cookies e histórico no lado do cliente. Não tem qualquer efeito sobre o SSRF, que ocorre no lado do servidor. A alternativa confunde SSRF com ataques que envolvem o navegador do usuário, como XSS ou CSRF.

Alternativa C — ✅ Correta ⟵ GABARITO

A criação de uma lista positiva (allowlist) de URLs permitidas é uma das principais medidas de prevenção contra SSRF, conforme recomendado pelo OWASP. Ao restringir os destinos que o servidor pode acessar, impede-se que o atacante explore a funcionalidade para alcançar recursos internos ou não autorizados. Essa é a medida mais direta e eficaz entre as opções.

Alternativa D — ❌ Incorreta

Trocar bancos de dados relacionais por NoSQL não tem relação com SSRF. O SSRF é uma vulnerabilidade de requisições HTTP do servidor, não de banco de dados. A alternativa confunde SSRF com SQL Injection ou com problemas de persistência de dados.

Alternativa E — ❌ Incorreta

Hospedar em servidores on-premises em vez de nuvens públicas não elimina o SSRF. O ataque pode ocorrer em qualquer ambiente, pois a vulnerabilidade está na aplicação, não na infraestrutura. A alternativa sugere uma falsa sensação de segurança, ignorando que o SSRF explora a lógica da aplicação.

Gabarito: letra C