O que é SSRF?

Em um ataque SSRF, o invasor normalmente manipula a entrada usada para especificar a URL de destino para uma solicitação HTTP do lado do servidor. Isso pode ocorrer quando um aplicativo não valida ou higieniza uma URL inserida por um usuário antes de extrair dados de um recurso remoto. O invasor pode fazer com que o servidor alvo execute solicitações para destinos arbitrários, o que pode levar a vários riscos de segurança. 

Esses ataques também podem acontecer se o recurso direcionado tiver relações de confiança com outros sistemas, como um serviço de metadados em nuvem ou APIs de back-end, permitindo que um invasor faça solicitações a esses serviços confiáveis e extraia informações confidenciais ou execute ações não autorizadas.

À medida que os aplicativos da web modernos oferecem recursos convenientes aos usuários finais, obter uma URL se tornou um cenário comum. Como resultado, a incidência de SSRF está aumentando. Além disso, a gravidade do SSRF aumenta à medida que APIs e serviços de nuvem se tornam mais prevalentes e as arquiteturas de computação mais descentralizadas e complexas.

O SSRF é um dos 10 principais riscos de segurança de aplicativos da OWASP , uma compilação amplamente reconhecida dos riscos de segurança de aplicativos web mais críticos. O SSRF também é um dos dez principais riscos de segurança da OWASP , comuns a aplicativos e APIs , e merece consideração especial ao implementar soluções de segurança. 

Veja como funciona um ataque SSRF:

• O aplicativo permite que o usuário insira informações para determinar o URL de destino ou o recurso para uma solicitação do lado do servidor. Essa entrada pode vir de parâmetros em uma URL, entradas do usuário em campos de formulário ou outras fontes de dados.
• O invasor envia uma solicitação especialmente elaborada, manipulando a entrada para apontar para um recurso que ele deseja acessar ou explorar. Este recurso pode ser um servidor interno, um serviço de backend, uma API ou outros sistemas internos que estão atrás de firewalls e não são acessíveis pela rede externa.
• O servidor processa a entrada maliciosa do usuário e constrói uma solicitação para a URL especificada. Essa solicitação é feita da perspectiva do servidor, não do navegador do usuário, o que a torna uma solicitação do lado do servidor.
• Se o servidor visado estiver dentro de uma rede interna, o invasor poderá tentar acessar e recuperar informações confidenciais de recursos internos e, em seguida, exfiltrar esses dados para um local externo controlado pelo invasor. O SSRF também pode ser usado para escanear portas em sistemas internos, ajudando o invasor a identificar possíveis fraquezas e vulnerabilidades.
• Os ataques SSRF são particularmente preocupantes em ambientes de nuvem, onde as instâncias podem ter acesso a serviços de metadados confidenciais.
• O impacto de um ataque SSRF pode ser grave, variando desde o acesso não autorizado a dados e serviços confidenciais até a exploração de sistemas internos e até mesmo o comprometimento de ambientes de nuvem inteiros.

Veja como um ataque SSRF pode acontecer na vida real.

Imagine um aplicativo web desprotegido que permite aos usuários carregar imagens para processamento, com um recurso que permite aos usuários fornecer um URL para uma imagem que desejam processar. No entanto, em vez de fornecer uma URL de imagem legítima, o invasor envia uma entrada cuidadosamente elaborada contendo uma URL maliciosa que aponta para um recurso interno no servidor do aplicativo, como um arquivo interno ou um banco de dados de back-end. O servidor de aplicativos processa cegamente a URL maliciosa e, seguindo a entrada do invasor, faz uma solicitação ao recurso interno especificado pela URL para buscar dados confidenciais ou consultar um banco de dados e retornar os dados ao invasor.

Depois que o servidor é comprometido, o invasor também pode fazer solicitações a sistemas externos, sondar vulnerabilidades ou interagir com serviços aos quais o servidor tem acesso. O impacto de um ataque SSRF pode variar com base na arquitetura do sistema e nas permissões do servidor comprometido. Ataques podem levar ao acesso não autorizado a dados, interrupção de serviços ou comprometimento de sistemas internos.

Os ataques SSRF podem ser classificados em diferentes tipos com base em como o invasor interage com o servidor e extrai informações.

Em um ataque SSRF padrão, o invasor injeta uma URL maliciosa como parte da entrada do usuário, acionando o servidor para fazer uma solicitação ao recurso especificado. O invasor pode observar diretamente a resposta do servidor e coletar informações sobre a rede interna, como recuperar dados ou identificar serviços acessíveis.

Em ataques SSRF cegos, o invasor não recebe diretamente a resposta do servidor. Em vez disso, o invasor confirma indiretamente o sucesso ou o fracasso do ataque SSRF observando mudanças no comportamento do aplicativo.

O invasor envia uma entrada elaborada, forçando o servidor a fazer uma solicitação a um recurso externo ou interno. O invasor procura por mudanças observáveis na atividade do aplicativo, como diferenças em mensagens de erro, tempos de resposta ou outros efeitos colaterais. Essas informações ajudam o invasor a inferir se o SSRF foi bem-sucedido, mesmo que o invasor não veja a resposta diretamente.

Os ataques cegos de SSRF baseados no tempo envolvem a exploração de atrasos nas respostas do servidor para inferir o sucesso ou a falha do SSRF sem ver diretamente a resposta.

Como em outros ataques SSRF, o invasor envia uma entrada maliciosa, fazendo com que o servidor faça uma solicitação a um recurso externo ou interno. O invasor observa o tempo que o aplicativo leva para responder. Atrasos no tempo de resposta podem indicar que o SSRF foi bem-sucedido. O invasor ajusta iterativamente a carga útil e monitora os atrasos para extrair informações sobre a rede interna ou os recursos.

Para se proteger contra ataques SSRF, implemente uma combinação de medidas preventivas de segurança cibernética, incluindo: 

• Validação de entrada. Valide e higienize rigorosamente as entradas fornecidas pelo usuário, especialmente quando o aplicativo estiver fazendo solicitações a recursos externos. Implemente a lista de permissões de URL, permitindo apenas domínios confiáveis ou URLs específicas que o aplicativo precisa acessar. Certifique-se de que apenas os protocolos esperados, como http e https, sejam permitidos e evite permitir protocolos potencialmente arriscados, como file:// ou ftp://, que geralmente são explorados em ataques SSRF. Além disso, valide se os URLs fornecidos pelos usuários seguem os padrões ou formatos esperados, reduzindo a probabilidade de injetar URLs maliciosos.
• Listas de permissões para hosts e endereços IP. Mantenha uma lista de permissões de hosts e endereços IP com os quais o aplicativo tem permissão para interagir. Isso pode ajudar a restringir solicitações a destinos confiáveis e pretendidos, reduzindo a superfície de ataque para SSRF. 
• Restrinja o acesso a recursos internos. Implemente a segmentação de rede para limitar a exposição de recursos internos. Garanta que os servidores externos tenham acesso mínimo aos sistemas e serviços internos. Configure firewalls de aplicativos da Web (WAFs) e controles de acesso para restringir conexões de saída do servidor de aplicativos. Permita apenas conexões necessárias e predefinidas e bloqueie tráfego de saída desnecessário. Implante um proxy reverso para atuar como intermediário entre o aplicativo e recursos externos. Configure o proxy para controlar quais recursos externos o aplicativo pode acessar, adicionando uma camada adicional de controle.

Como essas medidas preventivas ajudam a evitar ataques SSRF? Vamos analisar um cenário hipotético.

Um sistema de gerenciamento de conteúdo online permite que os usuários insiram URLs para incorporar imagens externas em suas postagens. Este sistema processa URLs fornecidas pelo usuário sem a devida validação de entrada. Um invasor, ciente da falta de validação de entrada, tenta explorar o sistema fornecendo uma URL maliciosa apontando para um recurso interno, como um ponto de extremidade de API interna ou um servidor de banco de dados. No entanto, a equipe de segurança do aplicativo aprimora a validação de entrada do sistema para impor regras rígidas em URLs aceitas. O sistema começa a validar se os URLs fornecidos pelos usuários seguem os padrões esperados e a equipe implementa uma lista de permissões de domínios permitidos para recursos externos. 

O invasor envia a postagem com uma URL criada com a intenção de explorar a falha do SSRF, mas a validação de entrada agora detecta a URL maliciosa. A validação de entrada rejeita a URL maliciosa durante o processamento, impedindo que o aplicativo faça uma solicitação ao recurso interno especificado pelo invasor. O ataque SSRF é frustrado pela validação de entrada aprimorada: O sistema não permite solicitações não autorizadas a recursos internos, e a integridade e a segurança dos sistemas internos são preservadas.

Ao implementar a validação de entrada, a aplicação pode rejeitar ou higienizar a entrada maliciosa, evitando solicitações não autorizadas e mitigando o risco de ataques de SSRF.

Os ataques SSRF são perigosos porque permitem que invasores ignorem medidas tradicionais de segurança de rede, como firewalls e controles de acesso, para acessar informações e recursos confidenciais que normalmente são protegidos dentro da rede interna de uma organização e não devem ser acessados diretamente pela Internet. Como os ataques SSRF representam riscos significativos à confidencialidade, integridade e disponibilidade de dados e sistemas, as organizações devem implementar medidas de segurança robustas e práticas recomendadas, incluindo WAFs, validação de entrada adequada, controles de acesso e segmentação de rede, para mitigar a ameaça de vulnerabilidades SSRF e proteger contra possível exploração.

As soluções F5 WAF bloqueiam e mitigam um amplo espectro de riscos decorrentes do OWASP Top 10 , incluindo SSRF. As soluções F5 WAF combinam proteções de assinatura e comportamentais, incluindo inteligência de ameaças do F5 Labs e segurança automatizada via aprendizado de máquina (ML) para acompanhar as ameaças emergentes. Eles aliviam a carga e a complexidade de proteger consistentemente aplicativos em nuvens, ambientes locais e de ponta, e estão disponíveis em diversas opções de implantação. O BIG-IP Advanced WAF é uma solução robusta que pode manter seus aplicativos protegidos contra ataques SSRF e fornecer uma solução paliativa crítica para vulnerabilidades de software, enquanto o F5 Distributed Cloud WAF protege aplicativos em qualquer lugar com operações drasticamente simplificadas por meio de uma plataforma de segurança como serviço fácil de usar.  

As soluções de proteção de API e aplicativos da Web (WAAP) da F5 defendem toda a superfície de ataque de aplicativos modernos com proteções abrangentes que incluem WAF, segurança de API , mitigação de DDoS L3-L7 e defesa de bots contra automação maliciosa e ameaças automatizadas. A plataforma distribuída simplifica a implantação de políticas consistentes e a escala de segurança em todo o seu conjunto de aplicativos e APIs, independentemente de onde estejam hospedados, além de integrar a segurança ao ciclo de vida da API e aos ecossistemas mais amplos.