Bug Bounty 2026-05-15 @reeshasx

WAF_EVASION_LOGS: Bypassing Enterprise Filters on High-Value Targets

[ 0x00 ] A ILUSÃO DO FILTRO PERFEITO

É comum no meio corporativo assumir que a presença de um WAF (Web Application Firewall) de classe empresarial (como Cloudflare Enterprise, Akamai Kona ou Imperva) é suficiente para imunizar aplicações web. Telas de 403 Forbidden dão a falsa sensação de barreiras intransponíveis.

No entanto, WAFs operam essencialmente como parsers de tráfego que comparam assinaturas de rede (expressões regulares) com o payload das requisições HTTP. O calcanhar de Aquiles dessa arquitetura reside na discrepância de interpretação de dados: onde há parsers encadeados e normalização de dados distinta, há brechas para desvios.

[ 0x01 ] DESSINCRONIZAÇÃO DE DECODIFICAÇÃO (DOUBLE URL ENCODING)

A técnica de Double URL Encoding explora falhas onde o WAF e o servidor backend realizam etapas assimétricas de decodificação de caracteres.

Ao enviar um payload simples como U%6eION S%45LECT (codificação URL simples), o WAF realiza a decodificação inicial, interceptando a string UNION SELECT e bloqueando a requisição. Contudo, na codificação dupla, codificamos o caractere especial de percentagem % (cujo código hexadecimal é %25), transformando o caractere n (%6e) em %256e.

Fase 1 (WAF): O firewall recebe U%256eION S%2545LECT. Ao aplicar uma única passagem de decodificação URL, a string é convertida para U%6eION S%45LECT. Como o filtro do WAF procura pela assinatura exata UNION SELECT, a requisição é classificada como inofensiva e liberada.
Fase 2 (Backend): O servidor web backend recebe a requisição liberada. Antes de passá-la para as rotinas de banco de dados, o interpretador (como PHP ou ASP) realiza a decodificação secundária dos valores, transformando U%6eION S%45LECT de volta para UNION SELECT. A consulta maliciosa é executada.

[ 0x02 ] POLUIÇÃO DE PARÂMETROS HTTP (HPP)

A Poluição de Parâmetros HTTP ocorre ao injetar múltiplos parâmetros com a mesma chave em uma única query string HTTP (ex: ?id=1&id=UNION+SELECT...). A vulnerabilidade ocorre porque diferentes servidores e frameworks web lidam com chaves duplicadas de maneiras distintas:

Servidor / Framework	Comportamento com Chaves Duplicadas	Resultado do Exemplo
ASP.NET / IIS	Concatenado com vírgula	`1,UNION SELECT...`
PHP / Apache	Retorna apenas o último valor	`UNION SELECT...`
JSP / Tomcat	Retorna apenas o primeiro valor	`1`
Express.js (Node.js)	Cria um array de strings	`['1', 'UNION SELECT...']`

Se o WAF for configurado para inspecionar apenas a primeira ocorrência do parâmetro id (visando economia de recursos), ele validará o valor seguro 1 e ignorará a ocorrência subsequente. No entanto, se o backend for estruturado sob PHP/Apache, ele processará o último valor (o payload SQLi), contornando a proteção.

[ 0x03 ] EXTRAÇÃO DE METADADOS DO LOG (ESTUDO DE CASO OPENRESTY)

Durante uma avaliação autorizada em um ativo empresarial protegido, identifiquei um WAF configurado para bloquear requisições com strings suspeitas em parâmetros comuns de requisição. A estratégia adotada consistiu em mover o payload para cabeçalhos HTTP exóticos (X-Forwarded-Host, X-Rewrite-URL, Client-IP).

Muitos gateways e proxies reversos (como Nginx e OpenResty) utilizam esses cabeçalhos para controle de rotas internas e logs. Ao enviar payloads com codificação Unicode específica e delimitadores nulos (%00) nestes cabeçalhos, causei um erro de tratamento no parser do proxy reverso.

Em vez de bloquear a conexão, o gateway mal configurado encaminhou a requisição para uma rota de erro interna que expôs o stack trace de debug do OpenResty. Isso revelou regras de roteamento internas e versões exatas de bibliotecas compartilhadas, permitindo mapear o ambiente interno sem acionar os alertas principais de intrusão do WAF.

[ 0x04 ] EVASÃO VIA TRANSFER-ENCODING: CHUNKED

Muitos filtros de WAF inspecionam apenas o cabeçalho Content-Length e o corpo da requisição POST até um limite de tamanho. Sob a especificação HTTP/1.1, podemos fragmentar a transmissão de dados utilizando o cabeçalho Transfer-Encoding: chunked.

Nesta modalidade, o corpo da requisição é enviado em blocos isolados. Cada bloco inicia com seu tamanho em formato hexadecimal, seguido de CRLF (\r\n), os dados e outro CRLF. A transmissão é finalizada obrigatoriamente com o chunk terminal de tamanho zero (0\r\n\r\n).

POST /api/upload HTTP/1.1
Host: target.local
Transfer-Encoding: chunked
Content-Type: application/x-www-form-urlencoded
Connection: close

1\r\n
<\r\n
1\r\n
s\r\n
1\r\n
c\r\n
1\r\n
r\r\n
1\r\n
i\r\n
1\r\n
p\r\n
1\r\n
t\r\n
0\r\n
\r\n

WAFs antigos que não remontam streams HTTP chunked analisam apenas os blocos de bytes isolados de 1 byte (que não possuem assinaturas maliciosas), liberando a requisição para o backend. O backend, por sua vez, realiza a remontagem em memória e executa o XSS completo.

[ 0x05 ] NORMALIZAÇÃO UNICODE E COMPATIBILIDADE DE TIPOS

O consórcio Unicode define regras de equivalência de caracteres para unificar variações gráficas. Existem formas de normalização canônica (NFC/NFD) e formas de normalização por compatibilidade (NFKC/NFKD). A normalização por compatibilidade (NFK) é amplamente empregada por bancos de dados e motores de busca para colapsar variantes gráficas de letras em seus equivalentes ASCII.

Por exemplo, o caractere do símbolo Kelvin K (U+212A) é canonicamente distincto da letra ASCII K (U+004B). No entanto, sob a normalização NFKC, U+212A é colapsado para U+004B.

Se um operador enviar um payload contendo SELECKT (usando o símbolo Kelvin): 1. Fase de Inspeção: O WAF realiza a análise estática em formato bruto ou utilizando normalização canônica (NFC). Ele determina que SELECKT não corresponde à palavra-chave restrita SELECT e libera o tráfego. 2. Fase de Execução: A normalização NFKC não ocorre de forma mágica no parser SQL bruto do banco de dados, mas sim nas rotinas de pré-processamento da aplicação, ORMs, adaptadores de conexão (que unificam charsets) ou na normalização interna de strings efetuada por mecanismos de indexação da aplicação antes da geração final da consulta.

Golden Tip: Testar filtros não se resume a automatizar cargas de ataque. Requer mapear e compreender o fluxo de dados em toda a cadeia tecnológica (Load Balancer -> WAF -> Proxy Reverso -> Backend Application -> Database) para identificar inconsistências de decodificação.

[ 0x00 ] THE ILLUSION OF THE IMPENETRABLE WALL

It is a common corporate assumption that deploying an enterprise-grade WAF (Web Application Firewall) such as Cloudflare Enterprise, Akamai Kona, or Imperva is sufficient to secure web applications. Seeing a 403 Forbidden alert screen often gives a false impression of security.

However, WAFs are fundamentally traffic parsers that match signature rules (regular expressions) against incoming HTTP request bodies. The primary weakness of this architecture lies in data interpretation asymmetry: where there are chained parsers and asymmetric data normalization, filter bypasses arise.

[ 0x01 ] CODING STATE DESYNCHRONIZATION (DOUBLE URL ENCODING)

The Double URL Encoding technique exploits vulnerabilities where the WAF and the backend application server perform asymmetric stages of URL decoding.

When sending a payload like U%6eION S%45LECT (single URL encoding), the WAF performs URL decoding, detects the restricted keyword UNION SELECT, and blocks the request. In double encoding, we encode the percent symbol % itself (whose hex value is %25), transforming the character n (%6e) into %256e.

Phase 1 (WAF): The WAF inspects U%256eION S%2545LECT. Applying a single stage of URL decoding, it decodes %25 to %, resulting in U%6eION S%45LECT. Since the WAF rules look for the exact string UNION SELECT, the request is classified as safe and allowed through.
Phase 2 (Backend): The backend application server receives the cleared request. Before passing the query to the database layer, the backend interpreter (such as PHP or ASP) executes a secondary URL decode, converting U%6eION S%45LECT back to UNION SELECT. The malicious query is executed.

[ 0x02 ] HTTP PARAMETER POLLUTION (HPP)

HTTP Parameter Pollution involves sending multiple query parameters with the identical key in a single HTTP request (e.g., ?id=1&id=UNION+SELECT...). The vulnerability is caused by different web engines parsing duplicate keys differently:

Web Server / Framework	Duplicate Key Resolution	Example Output
ASP.NET / IIS	Concatenates with a comma separator	`1,UNION SELECT...`
PHP / Apache	Resolves to the last parameter only	`UNION SELECT...`
JSP / Tomcat	Resolves to the first parameter only	`1`
Express.js (Node.js)	Creates an array of strings	`['1', 'UNION SELECT...']`

If the WAF is configured to parse only the first occurrence of the parameter id (often done to save CPU resources), it will validate the safe value 1 and ignore the subsequent payload. However, if the backend uses PHP/Apache, it will process the last parameter (the SQLi payload), bypassing the WAF entirely.

[ 0x03 ] METADATA EXPLOITATION IN GATEWAY LOGS (OPENRESTY CASE)

During an authorized assessment of an enterprise asset protected by a strict WAF, I observed that incoming traffic was blocked when suspicious patterns were found in standard query parameters. The evasion strategy consisted of moving the payload into non-standard HTTP headers (X-Forwarded-Host, X-Rewrite-URL, Client-IP).

Many reverse proxies (such as Nginx and OpenResty) process these headers for internal routing and logging. Injecting specific Unicode encodings and null bytes (%00) into these headers caused a parsing error in the proxy's header normalizer.

Instead of blocking the request, the proxy routed the connection to an internal error handler that returned an OpenResty debug page, exposing internal stack traces, routing paths, and library versions, allowing us to map the system topology without triggering alerts.

[ 0x04 ] EVASION VIA TRANSFER-ENCODING: CHUNKED

Most WAF filters only inspect the Content-Length header and analyze the POST body up to a certain byte threshold. Under the HTTP/1.1 specification, we can fragment the request payload using the Transfer-Encoding: chunked header.

In chunked mode, the request body is transmitted in separate chunks. Each chunk begins with its size in hexadecimal, followed by CRLF (\r\n), the chunk data, and another CRLF. The transmission is terminated using a zero-size chunk (0\r\n\r\n).

POST /api/upload HTTP/1.1
Host: target.local
Transfer-Encoding: chunked
Content-Type: application/x-www-form-urlencoded
Connection: close

1\r\n
<\r\n
1\r\n
s\r\n
1\r\n
c\r\n
1\r\n
r\r\n
1\r\n
i\r\n
1\r\n
p\r\n
1\r\n
t\r\n
0\r\n
\r\n

Older WAFs that do not reassemble chunked HTTP streams will only inspect the individual 1-byte data blocks (which do not match malicious signatures), allowing the request to pass. The backend server then reassembles the payload in memory, executing the payload. Note that standard Go/TinyGo WASM modules require loading the JavaScript bridge runtime (wasm_exec.js) to provide the necessary syscall bindings (go.importObject). In restricted environments, compilers must compile the bytecode as a standalone WASM library (WASI) exposing raw exports rather than launching the standard Go runtime lifecycle.

[ 0x05 ] UNICODE NORMALIZATION AND COMPATIBILITY MAPPINGS

The Unicode standard defines equivalence rules to represent character variants. It defines Canonical Equivalence (NFC/NFD) and Compatibility Equivalence (NFKC/NFKD). Compatibility normalization (NFK) is widely used by database engines and search tools to collapse graphical variations of characters into standard ASCII.

For instance, the Kelvin symbol K (U+212A) is canonicamente distinct from the standard ASCII uppercase letter K (U+004B). However, under NFKC normalization, U+212A collapses into U+004B.

If an operator sends a payload containing SELECKT (using the Kelvin symbol): 1. Inspection Phase: The WAF analyzes the raw string or applies NFC normalization. It determines that SELECKT does not match the restricted keyword SELECT and allows it. 2. Execution Phase: NFKC normalization typically does not occur natively inside the database's raw SQL engine parser, but is rather executed by application-level sanitizers, ORMs, database connection libraries, or string conversion logic within the application stack before the final SQL parsing phase.

Golden Tip: Testing web application firewalls is not about throwing random payloads. It is about understanding the data flow through the entire technological chain (Load Balancer -> WAF -> Reverse Proxy -> Backend Application -> Database) to find decoding discrepancies.