Segurança no servidor

O que é SSRF?

Como a falha aparece

Recursos como importar uma imagem por URL, validar um webhook ou gerar uma prévia de link precisam buscar conteúdo externo. O risco surge quando a aplicação aceita qualquer endereço e o servidor faz a requisição sem restrições suficientes.

Como o pedido parte do servidor, ele pode alcançar serviços internos, painéis administrativos, endpoints de metadados em nuvem ou outros destinos invisíveis para a internet pública. Redirecionamentos e diferenças entre a validação e a resolução real do endereço aumentam a complexidade.

Qual é o impacto

O resultado depende de onde o servidor está e do que ele consegue acessar. A falha pode permitir leitura de informações internas, interação com serviços protegidos apenas pela rede, varredura indireta ou uso do servidor como intermediário.

Mesmo quando a resposta não é exibida, tempo, status e tamanho podem revelar se um destino existe. Esse cenário é chamado frequentemente de SSRF cego.

Como prevenir

• Prefira uma lista explícita de destinos, esquemas e portas permitidos.
• Resolva e valide o endereço final, inclusive depois de redirecionamentos.
• Bloqueie acesso a faixas locais, privadas, link-local e endpoints de metadados.
• Separe o componente que faz requisições e limite sua saída de rede.
• Defina tempo limite, tamanho máximo de resposta e número máximo de redirecionamentos.
• Registre destinos recusados e padrões anormais para investigação.

Teste defensivo

Mapeie todas as funcionalidades que recebem URLs e documente os destinos realmente necessários. Em ambiente autorizado, verifique se o componente recusa endereços locais, protocolos inesperados e redirecionamentos para destinos proibidos. O teste deve considerar tanto a validação inicial quanto o endereço efetivamente acessado.

Referência

Consulte a cheat sheet de prevenção de SSRF da OWASP para estratégias por arquitetura.