<summary><strong>Impara l'hacking su AWS da zero a esperto con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se vuoi vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
## Bypass delle Regole ACL di Nginx con la Manipolazione del Percorso <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
[Nel seguente post](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) viene spiegato che ModSecurity v3 (fino alla versione 3.0.12) **ha implementato in modo improprio la variabile `REQUEST_FILENAME`** che avrebbe dovuto contenere il percorso accesso (fino all'inizio dei parametri). Questo perché eseguiva un URL decode per ottenere il percorso.\
Pertanto, una richiesta come `http://example.com/foo%3f';alert(1);foo=` in ModSecurity supporrà che il percorso sia solo `/foo` perché `%3f` viene trasformato in `?` terminando il percorso dell'URL, ma in realtà il percorso che il server riceverà sarà `/foo%3f';alert(1);foo=`.
Qualcosa di simile è accaduto nella versione 2 di Mod Security che ha permesso di ignorare una protezione che impediva agli utenti di accedere a file con estensioni specifiche relative ai file di backup (come ad esempio `.bak`) semplicemente inviando il punto URL codificato in `%2e`, ad esempio: `https://example.com/backup%2ebak`.
[Questa ricerca](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) menziona che era possibile ignorare le regole di AWS WAF applicate agli header HTTP inviando un header "malformato" che non veniva correttamente analizzato da AWS ma lo era dal server backend.
Era possibile aggirare AWS WAF perché non capiva che la riga successiva fa parte del valore dell'intestazione mentre il server NODEJS sì (questo è stato risolto).
<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se vuoi vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale PEASS & HackTricks**](https://peass.creator-spring.com)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**