Translated ['src/network-services-pentesting/pentesting-web/nginx.md'] t

src/network-services-pentesting/pentesting-web/nginx.md

@@ -16,7 +16,7 @@ proxy_pass http://127.0.0.1:8080/;
 }
 }
 ```
-In questa configurazione, `/etc/nginx` è designato come la directory radice. Questa impostazione consente l'accesso ai file all'interno della directory radice specificata, come `/hello.txt`. Tuttavia, è fondamentale notare che è definita solo una posizione specifica (`/hello.txt`). Non c'è configurazione per la posizione radice (`location / {...}`). Questa omissione significa che la direttiva root si applica globalmente, consentendo le richieste al percorso radice `/` di accedere ai file sotto `/etc/nginx`.
+In questa configurazione, `/etc/nginx` è designato come la directory radice. Questa impostazione consente l'accesso ai file all'interno della directory radice specificata, come `/hello.txt`. Tuttavia, è fondamentale notare che è definita solo una posizione specifica (`/hello.txt`). Non c'è configurazione per la posizione radice (`location / {...}`). Questa omissione significa che la direttiva root si applica globalmente, consentendo alle richieste al percorso radice `/` di accedere ai file sotto `/etc/nginx`.
 
 Una considerazione critica per la sicurezza deriva da questa configurazione. Una semplice richiesta `GET`, come `GET /nginx.conf`, potrebbe esporre informazioni sensibili servendo il file di configurazione di Nginx situato in `/etc/nginx/nginx.conf`. Impostare la root su una directory meno sensibile, come `/etc`, potrebbe mitigare questo rischio, ma potrebbe comunque consentire accessi non intenzionali ad altri file critici, inclusi altri file di configurazione, log di accesso e persino credenziali crittografate utilizzate per l'autenticazione di base HTTP.
 
@@ -28,7 +28,7 @@ location /imgs {
 alias /path/images/;
 }
 ```
-Questa configurazione è soggetta ad attacchi LFI a causa del server che interpreta richieste come `/imgs../flag.txt` come un tentativo di accedere a file al di fuori della directory prevista, risolvendo effettivamente a `/path/images/../flag.txt`. Questo difetto consente agli attaccanti di recuperare file dal filesystem del server che non dovrebbero essere accessibili tramite il web.
+Questa configurazione è soggetta ad attacchi LFI a causa del server che interpreta richieste come `/imgs../flag.txt` come un tentativo di accedere a file al di fuori della directory prevista, risolvendo effettivamente in `/path/images/../flag.txt`. Questo difetto consente agli attaccanti di recuperare file dal filesystem del server che non dovrebbero essere accessibili tramite il web.
 
 Per mitigare questa vulnerabilità, la configurazione dovrebbe essere regolata per:
 ```
@@ -48,7 +48,7 @@ alias../ => HTTP status code 403
 ```
 ## Restrizione del percorso non sicuro <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
 
-Controlla la seguente pagina per imparare come bypassare direttive come:
+Controlla la seguente pagina per imparare a bypassare direttive come:
 ```plaintext
 location = /admin {
 deny all;
@@ -67,7 +67,7 @@ deny all;
 > [!CAUTION]
 > Variabili vulnerabili `$uri` e `$document_uri` e questo può essere risolto sostituendole con `$request_uri`.
 >
-> Anche una regex può essere vulnerabile come:
+> Un regex può anche essere vulnerabile come:
 >
 > `location ~ /docs/([^/])? { … $1 … }` - Vulnerabile
 >
@@ -91,14 +91,14 @@ Connection: keep-alive
 Location: https://example.com/
 Detectify: clrf
 ```
-Scopri di più sui rischi dell'iniezione CRLF e della divisione della risposta su [https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/](https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/).
+Impara di più sui rischi dell'iniezione CRLF e della divisione della risposta su [https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/](https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/).
 
 Inoltre, questa tecnica è [**spiegata in questo intervento**](https://www.youtube.com/watch?v=gWQyWdZbdoY&list=PL0xCSYnG_iTtJe2V6PQqamBF73n7-f1Nr&index=77) con alcuni esempi vulnerabili e meccanismi di rilevamento. Ad esempio, per rilevare questa misconfigurazione da una prospettiva blackbox, potresti utilizzare queste richieste:
 
 - `https://example.com/%20X` - Qualsiasi codice HTTP
 - `https://example.com/%20H` - 400 Bad Request
 
-Se vulnerabile, il primo restituirà "X" poiché è un metodo HTTP valido e il secondo restituirà un errore poiché H non è un metodo valido. Quindi il server riceverà qualcosa come: `GET / H HTTP/1.1` e questo attiverà l'errore.
+Se vulnerabile, il primo restituirà "X" poiché è qualsiasi metodo HTTP e il secondo restituirà un errore poiché H non è un metodo valido. Quindi il server riceverà qualcosa come: `GET / H HTTP/1.1` e questo attiverà l'errore.
 
 Altri esempi di rilevamento potrebbero essere:
 
@@ -125,19 +125,69 @@ location /s3/ {
 proxy_pass https://company-bucket.s3.amazonaws.com$uri;
 }
 ```
-### Qualsiasi variabile
+### Any variable
 
-È stato scoperto che **i dati forniti dall'utente** potrebbero essere trattati come una **variabile Nginx** in determinate circostanze. La causa di questo comportamento rimane piuttosto elusiva, eppure non è rara né semplice da verificare. Questa anomalia è stata evidenziata in un rapporto di sicurezza su HackerOne, che può essere visualizzato [qui](https://hackerone.com/reports/370094). Ulteriori indagini sul messaggio di errore hanno portato all'identificazione della sua occorrenza all'interno del [modulo di filtro SSI del codice di Nginx](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365), individuando Server Side Includes (SSI) come causa principale.
+È stato scoperto che **i dati forniti dall'utente** potrebbero essere trattati come una **variabile Nginx** in determinate circostanze. La causa di questo comportamento rimane piuttosto elusiva, eppure non è rara né facile da verificare. Questa anomalia è stata evidenziata in un rapporto di sicurezza su HackerOne, che può essere visualizzato [qui](https://hackerone.com/reports/370094). Ulteriori indagini sul messaggio di errore hanno portato all'identificazione della sua occorrenza all'interno del [modulo di filtro SSI del codice di Nginx](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365), individuando le Server Side Includes (SSI) come causa principale.
 
 Per **rilevare questa misconfigurazione**, è possibile eseguire il seguente comando, che prevede l'impostazione di un'intestazione referer per testare la stampa delle variabili:
 ```bash
 $ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’
 ```
-Scans per questa misconfigurazione su sistemi hanno rivelato molteplici istanze in cui le variabili Nginx potevano essere stampate da un utente. Tuttavia, una diminuzione del numero di istanze vulnerabili suggerisce che gli sforzi per risolvere questo problema sono stati in qualche modo efficaci.
+Scans for this misconfiguration across systems revealed multiple instances where Nginx variables could be printed by a user. However, a decrease in the number of vulnerable instances suggests that efforts to patch this issue have been somewhat successful.
+
+### Using try_files with $URI$ARGS variables
+
+Following Nginx misconfiguration can lead to an LFI vulnerability:
+```
+location / {
+try_files $uri$args $uri$args/ /index.html;
+}
+```
+Nella nostra configurazione abbiamo la direttiva `try_files` che viene utilizzata per controllare l'esistenza di file in un ordine specificato. Nginx servirà il primo che troverà. La sintassi di base della direttiva `try_files` è la seguente:
+```
+try_files file1 file2 ... fileN fallback;
+```
+Nginx controllerà l'esistenza di ciascun file nell'ordine specificato. Se un file esiste, verrà servito immediatamente. Se nessuno dei file specificati esiste, la richiesta verrà passata all'opzione di fallback, che può essere un altro URI o una pagina di errore specifica.
+
+Tuttavia, quando si utilizzano le variabili `$uri$args` in questa direttiva, Nginx cercherà un file che corrisponde all'URI della richiesta combinato con eventuali argomenti della stringa di query. Pertanto, possiamo sfruttare questa configurazione:
+```
+http {
+server {
+root /var/www/html/public;
+
+location / {
+try_files $uri$args $uri$args/ /index.html;
+}
+}
+}
+```
+Con il seguente payload:
+```
+GET /?../../../../../../../../etc/passwd HTTP/1.1
+Host: example.com
+```
+Utilizzando il nostro payload, eseguiremo l'escape della directory root (definita nella configurazione di Nginx) e caricheremo il file `/etc/passwd`. Nei log di debug possiamo osservare come Nginx prova i file:
+```
+...SNIP...
+
+2025/07/11 15:49:16 [debug] 79694#79694: *4 trying to use file: "/../../../../../../../../etc/passwd" "/var/www/html/public/../../../../../../../../etc/passwd"
+2025/07/11 15:49:16 [debug] 79694#79694: *4 try file uri: "/../../../../../../../../etc/passwd"
+
+...SNIP...
+
+2025/07/11 15:49:16 [debug] 79694#79694: *4 http filename: "/var/www/html/public/../../../../../../../../etc/passwd"
+
+...SNIP...
+
+2025/07/11 15:49:16 [debug] 79694#79694: *4 HTTP/1.1 200 OK
+
+```
+PoC contro Nginx utilizzando la configurazione menzionata sopra:
+![Esempio di richiesta burp](../../images/nginx_try_files.png)
 
 ## Lettura della risposta raw del backend
 
-Nginx offre una funzionalità tramite `proxy_pass` che consente l'intercettazione di errori e intestazioni HTTP prodotte dal backend, con l'obiettivo di nascondere messaggi di errore e intestazioni interni. Questo viene realizzato da Nginx servendo pagine di errore personalizzate in risposta agli errori del backend. Tuttavia, sorgono sfide quando Nginx incontra una richiesta HTTP non valida. Tale richiesta viene inoltrata al backend così com'è, e la risposta raw del backend viene quindi inviata direttamente al client senza l'intervento di Nginx.
+Nginx offre una funzionalità tramite `proxy_pass` che consente l'intercettazione degli errori e degli header HTTP prodotti dal backend, con l'obiettivo di nascondere i messaggi di errore interni e gli header. Questo viene realizzato da Nginx servendo pagine di errore personalizzate in risposta agli errori del backend. Tuttavia, sorgono sfide quando Nginx incontra una richiesta HTTP non valida. Tale richiesta viene inoltrata al backend così come ricevuta, e la risposta raw del backend viene quindi inviata direttamente al client senza l'intervento di Nginx.
 
 Considera un esempio di scenario che coinvolge un'applicazione uWSGI:
 ```python
@@ -168,19 +218,19 @@ Per ulteriori informazioni, controlla [Danny Robinson e Rotem Bar](https://mediu
 
 ### **Intestazioni di risposta Maclicious**
 
-Come mostrato in [**questo articolo**](https://mizu.re/post/cors-playground), ci sono alcune intestazioni che, se presenti nella risposta del server web, cambieranno il comportamento del proxy Nginx. Puoi controllarle [**nella documentazione**](https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/):
+Come mostrato in [**questo writeup**](https://mizu.re/post/cors-playground), ci sono alcune intestazioni che, se presenti nella risposta del server web, cambieranno il comportamento del proxy Nginx. Puoi controllarle [**nei documenti**](https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/):
 
 - `X-Accel-Redirect`: Indica a Nginx di reindirizzare internamente una richiesta a una posizione specificata.
 - `X-Accel-Buffering`: Controlla se Nginx deve bufferizzare la risposta o meno.
 - `X-Accel-Charset`: Imposta il set di caratteri per la risposta quando si utilizza X-Accel-Redirect.
 - `X-Accel-Expires`: Imposta il tempo di scadenza per la risposta quando si utilizza X-Accel-Redirect.
-- `X-Accel-Limit-Rate`: Limita il tasso di trasferimento per le risposte quando si utilizza X-Accel-Redirect.
+- `X-Accel-Limit-Rate`: Limita la velocità di trasferimento per le risposte quando si utilizza X-Accel-Redirect.
 
 Ad esempio, l'intestazione **`X-Accel-Redirect`** causerà un **reindirizzamento** interno in nginx. Quindi avere una configurazione nginx con qualcosa come **`root /`** e una risposta dal server web con **`X-Accel-Redirect: .env`** farà sì che nginx invii il contenuto di **`/.env`** (Path Traversal).
 
 ### **Valore predefinito nella direttiva Map**
 
-Nella **configurazione di Nginx**, la direttiva `map` gioca spesso un ruolo nel **controllo dell'autorizzazione**. Un errore comune è non specificare un valore **predefinito**, il che potrebbe portare a accessi non autorizzati. Ad esempio:
+Nella **configurazione di Nginx**, la direttiva `map` gioca spesso un ruolo nel **controllo dell'autorizzazione**. Un errore comune è non specificare un valore **predefinito**, il che potrebbe portare ad accessi non autorizzati. Ad esempio:
 ```yaml
 http {
 map $uri $mappocallow {
@@ -209,11 +259,11 @@ resolver 8.8.8.8;
 ```
 ### **`proxy_pass` e direttive `internal`**
 
-La direttiva **`proxy_pass`** è utilizzata per reindirizzare le richieste ad altri server, sia internamente che esternamente. La direttiva **`internal`** garantisce che determinate posizioni siano accessibili solo all'interno di Nginx. Anche se queste direttive non sono vulnerabilità di per sé, la loro configurazione richiede un'attenta esaminazione per prevenire lacune di sicurezza.
+La direttiva **`proxy_pass`** viene utilizzata per reindirizzare le richieste ad altri server, sia internamente che esternamente. La direttiva **`internal`** garantisce che determinate posizioni siano accessibili solo all'interno di Nginx. Sebbene queste direttive non siano vulnerabilità di per sé, la loro configurazione richiede un'attenta analisi per prevenire lacune di sicurezza.
 
 ## proxy_set_header Upgrade & Connection
 
-Se il server nginx è configurato per passare le intestazioni Upgrade e Connection, un [**attacco h2c Smuggling**](../../pentesting-web/h2c-smuggling.md) potrebbe essere eseguito per accedere a endpoint protetti/interni.
+Se il server nginx è configurato per passare le intestazioni Upgrade e Connection, un [**attacco di Smuggling h2c**](../../pentesting-web/h2c-smuggling.md) potrebbe essere eseguito per accedere a endpoint protetti/interni.
 
 > [!CAUTION]
 > Questa vulnerabilità consentirebbe a un attaccante di **stabilire una connessione diretta con l'endpoint `proxy_pass`** (`http://backend:9999` in questo caso) il cui contenuto non verrà controllato da nginx.