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

This commit is contained in:
Translator 2025-07-12 09:40:02 +00:00
parent 4de9c86779
commit e169d168c1
2 changed files with 67 additions and 17 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 190 KiB

View File

@ -22,15 +22,15 @@ Kritična bezbednosna razmatranja proizilaze iz ove konfiguracije. Jednostavan `
## Alias LFI Misconfiguration <a href="#alias-lfi-misconfiguration" id="alias-lfi-misconfiguration"></a>
U konfiguracionim datotekama Nginx-a, neophodno je pažljivo pregledati "location" direktive. Ranljivost poznata kao Local File Inclusion (LFI) može biti nenamerno uvedena kroz konfiguraciju koja podseća na sledeću:
U konfiguracionim datotekama Nginx-a, neophodno je pažljivo ispitivanje "location" direktiva. Ranljivost poznata kao Local File Inclusion (LFI) može biti nenamerno uvedena kroz konfiguraciju koja podseća na sledeću:
```
location /imgs {
alias /path/images/;
}
```
Ova konfiguracija je podložna LFI napadima zbog toga što server interpretira zahteve poput `/imgs../flag.txt` kao pokušaj pristupa datotekama van predviđene direktorijuma, što se efektivno rešava u `/path/images/../flag.txt`. Ova greška omogućava napadačima da preuzmu datoteke sa serverovog fajl sistema koje ne bi trebale biti dostupne putem veba.
Ova konfiguracija je podložna LFI napadima zbog toga što server interpretira zahteve kao što je `/imgs../flag.txt` kao pokušaj pristupa datotekama van predviđene direktorijuma, što se efektivno rešava u `/path/images/../flag.txt`. Ova greška omogućava napadačima da preuzmu datoteke sa serverovog fajl sistema koje ne bi trebale biti dostupne putem veba.
Da bi se ublažila ova ranjivost, konfiguracija bi trebala biti prilagođena da:
Da bi se ublažila ova ranjivost, konfiguracija bi trebala biti prilagođena na:
```
location /imgs/ {
alias /path/images/;
@ -65,9 +65,9 @@ deny all;
## Nepravilna upotreba varijabli / HTTP Request Splitting <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
> [!CAUTION]
> Ranljive varijable `$uri` i `$document_uri` i ovo se može ispraviti zamenom sa `$request_uri`.
> Ranljive varijable `$uri` i `$document_uri` i ovo se može popraviti zamenom sa `$request_uri`.
>
> Regex može takođe biti ranjiv kao:
> Regex može biti takođe ranjiv kao:
>
> `location ~ /docs/([^/])? { … $1 … }` - Ranjiv
>
@ -81,7 +81,7 @@ location / {
return 302 https://example.com$uri;
}
```
Karakteri \r (Carriage Return) i \n (Line Feed) označavaju karaktere novog reda u HTTP zahtevima, a njihovi URL-enkodirani oblici predstavljeni su kao `%0d%0a`. Uključivanje ovih karaktera u zahtev (npr., `http://localhost/%0d%0aDetectify:%20clrf`) na pogrešno konfigurisanoj serveru rezultira time da server izdaje novi header pod nazivom `Detectify`. To se dešava zato što $uri varijabla dekodira URL-enkodirane karaktere novog reda, što dovodi do neočekivanog headera u odgovoru:
Karakteri \r (Carriage Return) i \n (Line Feed) označavaju karaktere novog reda u HTTP zahtevima, a njihovi URL-enkodirani oblici predstavljeni su kao `%0d%0a`. Uključivanje ovih karaktera u zahtev (npr., `http://localhost/%0d%0aDetectify:%20clrf`) na pogrešno konfigurisanoj serveru rezultira time da server izda novi header pod nazivom `Detectify`. To se dešava jer $uri varijabla dekodira URL-enkodirane karaktere novog reda, što dovodi do neočekivanog headera u odgovoru:
```
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.19.3
@ -113,7 +113,7 @@ location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}
```
- Obratite pažnju kako je ponovo **`$uri`** u URL-u (ovog puta unutar parametra)
- Imajte na umu kako je ponovo **`$uri`** u URL-u (ovog puta unutar parametra)
```
location ~ ^/dna/payment {
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
@ -127,17 +127,67 @@ proxy_pass https://company-bucket.s3.amazonaws.com$uri;
```
### Any variable
Otkriveno je da **podaci koje unosi korisnik** mogu biti tretirani kao **Nginx varijabla** pod određenim okolnostima. Uzrok ovog ponašanja ostaje donekle nejasan, ali nije retko niti jednostavno za verifikaciju. Ova anomalija je istaknuta u bezbednosnom izveštaju na HackerOne, koji se može pogledati [ovde](https://hackerone.com/reports/370094). Dalja istraga o poruci greške dovela je do identifikacije njenog pojavljivanja unutar [SSI filter modula Nginx-ove kodne baze](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365), ukazujući na Server Side Includes (SSI) kao osnovni uzrok.
Otkriveno je da **podaci koje unosi korisnik** mogu biti tretirani kao **Nginx varijabla** pod određenim okolnostima. Uzrok ovog ponašanja ostaje donekle nejasan, ali nije retko niti jednostavno za proveru. Ova anomalija je istaknuta u bezbednosnom izveštaju na HackerOne, koji se može pogledati [here](https://hackerone.com/reports/370094). Dalja istraga o poruci greške dovela je do identifikacije njenog pojavljivanja unutar [SSI filter modula Nginx-ovog koda](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365), ukazujući na Server Side Includes (SSI) kao osnovni uzrok.
Da bi se **otkrila ova pogrešna konfiguracija**, može se izvršiti sledeća komanda, koja uključuje postavljanje referer zaglavlja za testiranje štampanja varijable:
```bash
$ curl -H Referer: bar http://localhost/foo$http_referer | grep foobar
```
Skeneri za ovu pogrešnu konfiguraciju širom sistema otkrili su više instanci gde su Nginx varijable mogle biti prikazane od strane korisnika. Međutim, smanjenje broja ranjivih instanci sugeriše da su napori za ispravku ovog problema bili donekle uspešni.
Skeniranja za ovu pogrešnu konfiguraciju širom sistema otkrila su više instanci gde su Nginx varijable mogle biti štampane od strane korisnika. Međutim, smanjenje broja ranjivih instanci sugeriše da su napori da se reši ovaj problem donekle bili uspešni.
### Korišćenje try_files sa $URI$ARGS varijablama
Sledeća Nginx pogrešna konfiguracija može dovesti do LFI ranjivosti:
```
location / {
try_files $uri$args $uri$args/ /index.html;
}
```
U našoj konfiguraciji imamo direktivu `try_files` koja se koristi za proveru postojanja fajlova u određenom redosledu. Nginx će poslužiti prvi koji pronađe. Osnovna sintaksa direktive `try_files` je sledeća:
```
try_files file1 file2 ... fileN fallback;
```
Nginx će proveriti postojanje svake datoteke u navedenom redosledu. Ako datoteka postoji, biće odmah poslužena. Ako nijedna od navedenih datoteka ne postoji, zahtev će biti prosleđen opciji za rezervu, koja može biti druga URI ili specifična stranica sa greškom.
Međutim, kada se koriste `$uri$args` promenljive u ovoj direktivi, Nginx će pokušati da potraži datoteku koja odgovara URI zahteva kombinovanoj sa bilo kojim argumentima upita. Stoga možemo iskoristiti ovu konfiguraciju:
```
http {
server {
root /var/www/html/public;
location / {
try_files $uri$args $uri$args/ /index.html;
}
}
}
```
Sa sledećim payload-om:
```
GET /?../../../../../../../../etc/passwd HTTP/1.1
Host: example.com
```
Koristeći naš payload, izaći ćemo iz root direktorijuma (definisanog u Nginx konfiguraciji) i učitati datoteku `/etc/passwd`. U debug logovima možemo posmatrati kako Nginx pokušava datoteke:
```
...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 protiv Nginx koristeći konfiguraciju pomenutu iznad:
![Example burp request](../../images/nginx_try_files.png)
## Čitanje sirovog odgovora backend-a
Nginx nudi funkciju putem `proxy_pass` koja omogućava presretanje grešaka i HTTP zaglavlja koja proizvodi backend, sa ciljem skrivanja internih poruka o greškama i zaglavlja. To se postiže tako što Nginx služi prilagođene stranice grešaka kao odgovor na greške backend-a. Međutim, izazovi se javljaju kada Nginx naiđe na nevažeći HTTP zahtev. Takav zahtev se prosleđuje backend-u onako kako je primljen, a sirovi odgovor backend-a se zatim direktno šalje klijentu bez intervencije Nginx-a.
Nginx nudi funkciju kroz `proxy_pass` koja omogućava presretanje grešaka i HTTP zaglavlja koja proizvodi backend, sa ciljem da sakrije interne poruke grešaka i zaglavlja. To se postiže tako što Nginx servira prilagođene stranice grešaka kao odgovor na greške backend-a. Međutim, izazovi se javljaju kada Nginx naiđe na nevažeći HTTP zahtev. Takav zahtev se prosleđuje backend-u onako kako je primljen, a sirovi odgovor backend-a se zatim direktno šalje klijentu bez intervencije Nginx-a.
Razmotrite primer scenarija koji uključuje uWSGI aplikaciju:
```python
@ -153,16 +203,16 @@ proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}
```
- [**proxy_intercept_errors**](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_intercept_errors): Ova direktiva omogućava Nginxu da poslužuje prilagođeni odgovor za pozadinske odgovore sa status kodom većim od 300. Osigurava da, za naš primer uWSGI aplikacije, `500 Error` odgovor bude presretnut i obrađen od strane Nginxa.
- [**proxy_intercept_errors**](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_intercept_errors): Ova direktiva omogućava Nginxu da služi prilagođeni odgovor za odgovore sa pozadinskog sistema koji imaju status kod veći od 300. Osigurava da, za naš primer uWSGI aplikacije, `500 Error` odgovor bude presretnut i obrađen od strane Nginxa.
- [**proxy_hide_header**](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_hide_header): Kao što ime sugeriše, ova direktiva skriva određene HTTP zaglavlja od klijenta, poboljšavajući privatnost i sigurnost.
Kada se izvrši važeći `GET` zahtev, Nginx ga obrađuje normalno, vraćajući standardni odgovor o grešci bez otkrivanja bilo kakvih tajnih zaglavlja. Međutim, nevažeći HTTP zahtev zaobilazi ovaj mehanizam, što rezultira izlaganjem sirovih pozadinskih odgovora, uključujući tajna zaglavlja i poruke o grešci.
Kada se izvrši važeći `GET` zahtev, Nginx ga obrađuje normalno, vraćajući standardni odgovor o grešci bez otkrivanja bilo kakvih tajnih zaglavlja. Međutim, nevažeći HTTP zahtev zaobilazi ovaj mehanizam, što rezultira izlaganjem sirovih odgovora sa pozadinskog sistema, uključujući tajna zaglavlja i poruke o grešci.
## merge_slashes postavljeno na off
Podrazumevano, Nginxova **`merge_slashes` direktiva** je postavljena na **`on`**, što kompresuje više uzastopnih kose crte u URL-u u jednu kose crtu. Ova funkcija, iako pojednostavljuje obradu URL-a, može nenamerno prikriti ranjivosti u aplikacijama iza Nginxa, posebno onima koje su podložne napadima lokalnog uključivanja datoteka (LFI). Stručnjaci za bezbednost **Danny Robinson i Rotem Bar** su istakli potencijalne rizike povezane sa ovim podrazumevanjem, posebno kada Nginx deluje kao obrnuti proxy.
Podrazumevano, Nginxova **`merge_slashes` direktiva** je postavljena na **`on`**, što kompresuje više uzastopnih kose crte u URL-u u jednu kosu crtu. Ova funkcija, iako pojednostavljuje obradu URL-a, može nenamerno prikriti ranjivosti u aplikacijama iza Nginxa, posebno onima koje su podložne napadima lokalnog uključivanja datoteka (LFI). Stručnjaci za bezbednost **Danny Robinson i Rotem Bar** su istakli potencijalne rizike povezane sa ovim podrazumevanjem, posebno kada Nginx deluje kao obrnuti proxy.
Da bi se umanjili takvi rizici, preporučuje se da se **isključi `merge_slashes` direktiva** za aplikacije koje su podložne ovim ranjivostima. Ovo osigurava da Nginx prosledi zahteve aplikaciji bez izmene strukture URL-a, čime se ne prikrivaju nikakvi osnovni problemi sa bezbednošću.
Da bi se umanjili takvi rizici, preporučuje se **isključivanje `merge_slashes` direktive** za aplikacije koje su podložne ovim ranjivostima. Ovo osigurava da Nginx prosledi zahteve aplikaciji bez izmene strukture URL-a, čime se ne prikrivaju nikakvi osnovni problemi sa bezbednošću.
Za više informacija pogledajte [Danny Robinson i Rotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d).
@ -176,7 +226,7 @@ Kao što je prikazano u [**ovoj analizi**](https://mizu.re/post/cors-playground)
- `X-Accel-Expires`: Postavlja vreme isteka za odgovor kada se koristi X-Accel-Redirect.
- `X-Accel-Limit-Rate`: Ograničava brzinu prenosa za odgovore kada se koristi X-Accel-Redirect.
Na primer, zaglavlje **`X-Accel-Redirect`** će izazvati interno **preusmerenje** u Nginxu. Tako da, ako imate Nginx konfiguraciju sa nečim poput **`root /`** i odgovorom sa web servera sa **`X-Accel-Redirect: .env`**, Nginx će poslati sadržaj **`/.env`** (Path Traversal).
Na primer, zaglavlje **`X-Accel-Redirect`** će izazvati interno **preusmeravanje** u Nginxu. Tako da imati Nginx konfiguraciju sa nečim poput **`root /`** i odgovorom sa web servera sa **`X-Accel-Redirect: .env`** će nagnati Nginx da pošalje sadržaj **`/.env`** (Path Traversal).
### **Podrazumevana vrednost u Map direktivi**
@ -213,7 +263,7 @@ Direktiva **`proxy_pass`** se koristi za preusmeravanje zahteva na druge servere
## proxy_set_header Upgrade & Connection
Ako je nginx server konfigurisan da prosledi Upgrade i Connection zaglavlja, može se izvesti [**h2c Smuggling napad**](../../pentesting-web/h2c-smuggling.md) kako bi se pristupilo zaštićenim/internim krajnjim tačkama.
Ako je nginx server konfigurisan da prosledi Upgrade i Connection zaglavlja, može se izvršiti [**h2c Smuggling napad**](../../pentesting-web/h2c-smuggling.md) kako bi se pristupilo zaštićenim/internim krajnjim tačkama.
> [!CAUTION]
> Ova ranjivost bi omogućila napadaču da **uspostavi direktnu vezu sa `proxy_pass` krajnjom tačkom** (`http://backend:9999` u ovom slučaju) čiji sadržaj neće biti proveravan od strane nginx-a.
@ -251,7 +301,7 @@ Detectify je kreirao GitHub repozitorijum gde možete koristiti Docker da postav
### [GIXY](https://github.com/yandex/gixy)
Gixy je alat za analizu Nginx konfiguracije. Glavni cilj Gixy je sprečavanje sigurnosnih pogrešnih konfiguracija i automatizacija otkrivanja grešaka.
Gixy je alat za analizu Nginx konfiguracije. Glavni cilj Gixy je da spreči bezbednosne pogrešne konfiguracije i automatizuje otkrivanje grešaka.
### [Nginxpwner](https://github.com/stark0de/nginxpwner)