# Bypassando Proteções de Proxy / WAF
Aprenda hacking na AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)! Outras maneiras de apoiar o HackTricks: * Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com) * Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family) * **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
{% embed url="https://websec.nl/" %} ## Bypass de Regras ACL do Nginx com Manipulação de Nomes de Caminho Técnicas [desta pesquisa](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies). Exemplo de regra do Nginx: ```plaintext location = /admin { deny all; } location = /admin/ { deny all; } ``` Para evitar bypasses, o Nginx realiza a normalização de caminho antes de verificá-lo. No entanto, se o servidor backend realizar uma normalização diferente (removendo caracteres que o nginx não remove), pode ser possível contornar essa defesa. ### **NodeJS - Express** | Versão do Nginx | **Caracteres de Bypass do Node.js** | | --------------- | ----------------------------------- | | 1.22.0 | `\xA0` | | 1.21.6 | `\xA0` | | 1.20.2 | `\xA0`, `\x09`, `\x0C` | | 1.18.0 | `\xA0`, `\x09`, `\x0C` | | 1.16.1 | `\xA0`, `\x09`, `\x0C` | ### **Flask** | Versão do Nginx | **Caracteres de Bypass do Flask** | | --------------- | -------------------------------------------------------------------- | | 1.22.0 | `\x85`, `\xA0` | | 1.21.6 | `\x85`, `\xA0` | | 1.20.2 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | | 1.18.0 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | | 1.16.1 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | ### **Spring Boot** | Versão do Nginx | **Caracteres de Bypass do Spring Boot** | | --------------- | --------------------------------------- | | 1.22.0 | `;` | | 1.21.6 | `;` | | 1.20.2 | `\x09`, `;` | | 1.18.0 | `\x09`, `;` | | 1.16.1 | `\x09`, `;` | ### **PHP-FPM** Configuração do Nginx FPM: ```plaintext location = /admin.php { deny all; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.1-fpm.sock; } ``` Nginx está configurado para bloquear o acesso a `/admin.php`, mas é possível contornar isso acessando `/admin.php/index.php`. ### Como prevenir ```plaintext location ~* ^/admin { deny all; } ``` ## Bypassar Regras do Mod Security ### 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 de forma inadequada a variável `REQUEST_FILENAME`** que deveria conter o caminho acessado (até o início dos parâmetros). Isso ocorreu porque ele realizava um decode 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 `?` terminando o caminho do URL, mas na realidade o caminho que o servidor receberá será `/foo%3f';alert(1);foo=`. As variáveis `REQUEST_BASENAME` e `PATH_INFO` também foram afetadas por esse bug. Algo semelhante ocorreu na versão 2 do Mod Security que permitia contornar uma proteção que impedia o usuário de acessar arquivos com extensões específicas relacionadas a arquivos de backup (como `.bak`) simplesmente enviando o ponto codificado em URL em `%2e`, por exemplo: `https://example.com/backup%2ebak`. ## Bypassar AWS WAF ACL ### 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 nos cabeçalhos HTTP enviando um cabeçalho "malformado" que não era corretamente analisado pela AWS, mas sim pelo servidor backend. Por exemplo, enviando a seguinte solicitação com uma injeção de SQL no cabeçalho X-Query: ```http GET / HTTP/1.1\r\n Host: target.com\r\n X-Query: Value\r\n \t' or '1'='1' -- \r\n Connection: close\r\n \r\n ``` Foi possível contornar o AWS WAF porque ele não entendia que a próxima linha fazia parte do valor do cabeçalho, enquanto o servidor NODEJS entendia (isso foi corrigido). ## Referências * [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) * [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
{% embed url="https://websec.nl/" %}
Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)! Outras maneiras de apoiar o HackTricks: * Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com) * Descubra [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family) * **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Compartilhe seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).