Post cover image
Yonkous CTF Team

September 5, 2026

Bypass de WAF IMPERVA pra SSRF: quando o parser do WAF não entende o mesmo que o backend

Autor: Yuri Assis

By Yuri Assis

5 min read

[Esse bypass pode ser replicado em outros WAF's]

Severidade: High -WAF Bypass + SSRF

Introdução

Durante um teste de segurança autorizado, identifiquei um endpoint de proxy reverso protegido por um WAF que apresentava comportamento interessante: determinadas requisições eram bloqueadas pelo WAF quando utilizavam formatos convencionais, mas conseguiam alcançar a aplicação quando a mesma informação era representada de outra forma.

O ponto central da pesquisa foi uma diferença de interpretação entre:

WAF → Backend → Parser da aplicação

Enquanto o WAF analisava determinados valores como strings aparentemente inofensivas, o backend era capaz de interpretá-los como endereços IP, protocolos ou caminhos válidos.

Esse tipo de cenário é conhecido como parser differential e pode resultar em bypass de controles de segurança.

⚠️ Todas as técnicas descritas foram utilizadas exclusivamente em ambiente autorizado.

1. Descoberta

Durante a análise dos headers de segurança da aplicação, foi identificado um endpoint de proxy semelhante a:

https://api.target.example/proxy?url=<destino>

O parâmetro url permitia que a aplicação realizasse uma requisição para o destino especificado.

Em uma implementação desse tipo, o principal risco é SSRF — Server-Side Request Forgery.

O problema não está necessariamente no proxy existir, mas em como o destino fornecido pelo usuário é validado antes de ser processado pelo backend.

2. Comportamento do WAF

Testes iniciais demonstraram que padrões conhecidos eram identificados pelo WAF.

Exemplos de categorias bloqueadas:

🚫CategoriaResultadoLoopback em formato convencional

🚫 BloqueadoCloud metadata em formato convencional

🚫 BloqueadoDomínios de interação externa conhecidos

🚫 BloqueadoPayloads clássicos de SQL Injection

🚫 BloqueadoDeterminados caminhos sensíveis

🚫 Bloqueado

Em alguns casos, a resposta retornada era uma página HTML genérica associada ao mecanismo de proteção.

Isso permitiu estabelecer uma diferença importante:

Resposta do WAF ≠ resposta da aplicação

3. A hipótese: parser differential

A partir desse comportamento, surgiu uma hipótese:

O WAF estaria analisando a URL de uma maneira diferente daquela utilizada pelo backend.

Essa diferença pode acontecer quando diferentes componentes normalizam uma entrada de maneiras distintas.

Por exemplo:

Cliente
   │
   ▼
WAF
   │
   │  "valor não parece perigoso"
   ▼
Backend
   │
   │  "valor representa um endereço interno"
   ▼
Serviço interno

Esse é um dos conceitos mais importantes para compreender bypasses modernos de WAF.

Não basta perguntar se o WAF bloqueia determinado payload.

É necessário perguntar:

Como cada componente interpreta esse payload?

4. Representações alternativas de IP

Uma das técnicas analisadas foi a utilização de representações alternativas para endereços IPv4.

Por exemplo, um endereço IPv4 pode possuir representações além da tradicional notação decimal pontuada.

Conceitualmente:

127.0.0.1

pode ser representado de outras maneiras por determinados parsers.

Uma dessas representações é a forma hexadecimal:

0x7f000001

Se o WAF não normalizar esse valor antes da aplicação das regras, pode ocorrer:

WAF
 ↓
"0x7f000001"
 ↓
não reconhecido como loopback
 ↓
ALLOW

Enquanto o backend pode interpretar:

0x7f000001
 ↓
127.0.0.1

O resultado é uma divergência entre os controles de segurança e o componente que efetivamente realiza a conexão.

5. IPv6 Loopback

Outra representação relevante é o loopback IPv6:

::1

Um filtro que procure exclusivamente por:

127.0.0.1
localhost

pode não reconhecer automaticamente todas as representações equivalentes de loopback.

Novamente, o problema não é exclusivamente a regra do WAF.

O problema é a ausência de normalização canônica antes da validação.

6. Protocolos alternativos

Outro ponto importante foi a análise do esquema utilizado pelo parâmetro url.

Um proxy genérico que aceita:

http://
https://
file://
gopher://

possui uma superfície de ataque significativamente maior do que um proxy restrito a HTTP/HTTPS.

Por exemplo:

http://
https://

representam um conjunto relativamente previsível de comportamentos.

Já protocolos como:

file://
gopher://

podem permitir interações completamente diferentes dependendo da implementação do cliente HTTP/proxy.

Por isso, validar somente o domínio ou o endereço de destino não é suficiente.

O esquema também precisa ser validado.

7. A importância da normalização

Um dos principais aprendizados desse tipo de teste é que uma blacklist baseada em strings possui limitações.

Imagine uma regra:

bloquear "127.0.0.1"

Ela pode ser facilmente insuficiente se o parser posterior aceitar:

localhost
::1
representações numéricas alternativas
representações IPv4 alternativas

O mesmo princípio vale para caminhos:

/etc/passwd

Uma assinatura específica para esse caminho não significa necessariamente que outros caminhos sensíveis estejam protegidos.

Portanto:

Blacklists devem ser consideradas uma camada complementar, não a principal barreira de segurança.

8. Evidência de que a requisição atravessou o WAF

Um dos pontos mais interessantes da análise foi diferenciar as respostas produzidas pelo WAF das respostas produzidas pela aplicação.

Quando uma requisição era bloqueada, era retornada uma resposta característica do mecanismo de proteção.

Quando determinada representação conseguia passar pelo filtro, a resposta apresentava características diferentes, como:

{
  "errorCode": "BAD_REQUEST"
}

Essa diferença é extremamente útil durante uma investigação.

Mesmo quando o SSRF não retorna diretamente o conteúdo do serviço interno, a mudança de:

WAF response

para:

Application response

pode indicar que a requisição ultrapassou uma determinada camada de proteção.

Isso é um excelente exemplo de como side channels de resposta podem ajudar na validação de hipóteses durante um pentest.

9. Modelo mental do ataque

O cenário pode ser simplificado da seguinte forma:

┌──────────────┐
│    Cliente   │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│     WAF      │
│              │
│ String-based │
│ inspection   │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│    Proxy     │
│   Backend    │
└──────┬───────┘
       │
       │ URL parsing
       ▼
┌──────────────┐
│ Serviço      │
│ interno      │
└──────────────┘

O problema aparece quando:

WAF interpretation
        ≠
Backend interpretation

Essa diferença pode transformar um filtro aparentemente eficiente em um controle incompleto.

10. Impacto potencial

Uma vulnerabilidade SSRF em um proxy genérico pode permitir, dependendo das condições do ambiente:

  • Acesso a serviços internos;
  • Descoberta de portas;
  • Interação com APIs administrativas;
  • Acesso a endpoints internos;
  • Tentativas de acesso a serviços de infraestrutura;
  • Acesso a metadados de cloud;
  • Leitura de arquivos, caso protocolos locais sejam aceitos;
  • Interação com serviços que utilizem protocolos alternativos;
  • Pivoting para outros componentes da infraestrutura.

O impacto real depende diretamente de:

  1. Permissões do processo;
  2. Segmentação de rede;
  3. Regras de firewall;
  4. Serviços disponíveis internamente;
  5. Protocolos suportados pelo proxy;
  6. Capacidade de leitura da resposta;
  7. Controles adicionais implementados no backend.

11. O verdadeiro problema não é o WAF

É importante destacar que o objetivo de um WAF não é substituir a validação de segurança da aplicação.

Um WAF funciona como uma camada adicional.

O modelo correto deveria ser:

Internet
   │
   ▼
WAF
   │
   ▼
Application validation
   │
   ▼
URL normalization
   │
   ▼
Destination validation
   │
   ▼
Network controls
   │
   ▼
Internal services

Se o backend simplesmente confia que:

"O WAF já bloqueou os destinos perigosos"

existe uma dependência de segurança extremamente frágil.

12. Recomendações

Para aplicações que implementam proxies ou funcionalidades semelhantes, algumas medidas são fundamentais.

1. Allowlist de protocolos

Aceitar exclusivamente os esquemas necessários:

https://
http://

E rejeitar protocolos não necessários.

2. Normalização antes da validação

O endereço deve ser convertido para uma representação canônica antes de qualquer decisão de segurança.

É necessário considerar:

  • IPv4;
  • IPv6;
  • loopback;
  • private ranges;
  • link-local;
  • multicast;
  • representações numéricas alternativas;
  • DNS resolution;
  • redirects.

3. Bloquear destinos internos

A aplicação deve impedir acesso a:

127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16
::1/128
fc00::/7

Além de outras ranges relevantes ao ambiente.

4. Controlar redirects

Mesmo que o primeiro destino seja permitido, um redirect pode levar a:

public.example
      ↓
internal-service

Por isso, redirects também precisam passar por validação.

5. Preferir allowlist

Quando possível:

ALLOW
api.example.com
service.example.com

é significativamente mais seguro do que tentar construir uma blacklist infinita de destinos proibidos.

13. O que esse caso ensina

O principal aprendizado dessa pesquisa não é uma técnica específica de bypass.

É um princípio de arquitetura:

Todos os componentes que tomam decisões de segurança precisam interpretar a entrada de maneira consistente.

Um WAF pode bloquear:

127.0.0.1

mas isso não significa que bloqueou todas as representações semanticamente equivalentes.

Da mesma forma, bloquear:

/etc/passwd

não significa que todos os caminhos sensíveis foram protegidos.

E bloquear:

http://

não significa que outros esquemas não possam ser utilizados.

14. Conclusão

Esse tipo de vulnerabilidade demonstra uma classe interessante de problemas de segurança:

Parser Differential + SSRF + WAF Bypass

O WAF pode enxergar:

string aparentemente inofensiva

enquanto o backend enxerga:

endereço interno válido

A diferença entre essas duas interpretações pode ser suficiente para atravessar uma camada inteira de defesa.

A principal recomendação para desenvolvedores e equipes de segurança é simples:

Não confie no WAF para validar lógica de segurança da aplicação.

A validação precisa existir no próprio backend, utilizando normalização, allowlists, controle de protocolos, validação de DNS/IP e segmentação de rede.

WAF deve ser defense in depth, não a única linha de defesa.

⚠️ Disclaimer

Este artigo descreve técnicas observadas durante uma avaliação de segurança autorizada. Os exemplos foram anonimizados e devem ser utilizados exclusivamente em ambientes próprios, laboratórios ou sistemas nos quais exista autorização explícita para testes de segurança.

#CyberSecurity #Pentest #AppSec #SSRF #WAF #WebSecurity #EthicalHacking #BugBounty #InformationSecurity #RedTeam