Nginx

Reading time: 14 minutes

Ontbrekende wortel ligging

Wanneer die Nginx-bediener gekonfigureer word, speel die wortelriglyn 'n kritieke rol deur die basisgids te definieer waaruit lêers bedien word. Oorweeg die onderstaande voorbeeld:

server {
root /etc/nginx;

location /hello.txt {
try_files $uri $uri/ =404;
proxy_pass http://127.0.0.1:8080/;
}
}

In hierdie konfigurasie is /etc/nginx aangewys as die wortelgids. Hierdie opstelling stel toegang tot lêers binne die gespesifiseerde wortelgids moontlik, soos /hello.txt. Dit is egter belangrik om te noem dat slegs 'n spesifieke ligging (/hello.txt) gedefinieer is. Daar is geen konfigurasie vir die wortel ligging nie (location / {...}). Hierdie omissie beteken dat die wortelriglyn globaal van toepassing is, wat versoeke na die wortelpad / in staat stel om lêers onder /etc/nginx te benader.

'n Kritieke sekuriteitsoorweging ontstaan uit hierdie konfigurasie. 'n Eenvoudige GET versoek, soos GET /nginx.conf, kan sensitiewe inligting blootstel deur die Nginx konfigurasielêer wat geleë is by /etc/nginx/nginx.conf te bedien. Om die wortel na 'n minder sensitiewe gids, soos /etc, in te stel, kan hierdie risiko verminder, maar dit mag steeds onbedoelde toegang tot ander kritieke lêers, insluitend ander konfigurasielêers, toeganglogs en selfs versleutelde akrediteerings wat vir HTTP basiese outentisering gebruik word, toelaat.

Alias LFI Misconfiguration

In die konfigurasielêers van Nginx is 'n noukeurige ondersoek van die "location" riglyne nodig. 'n Kwessie bekend as Local File Inclusion (LFI) kan per ongeluk bekendgestel word deur 'n konfigurasie wat soos die volgende lyk:

location /imgs {
alias /path/images/;
}

Hierdie konfigurasie is geneig tot LFI-aanvalle omdat die bediener versoeke soos /imgs../flag.txt interpreteer as 'n poging om lêers buite die bedoelde gids te benader, wat effektief oplos na /path/images/../flag.txt. Hierdie fout laat aanvallers toe om lêers van die bediener se lêerstelsel te verkry wat nie via die web toeganklik behoort te wees nie.

Om hierdie kwesbaarheid te verminder, moet die konfigurasie aangepas word na:

location /imgs/ {
alias /path/images/;
}

Meer inligting: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/

Accunetix toetse:

alias../ => HTTP status code 403
alias.../ => HTTP status code 404
alias../../ => HTTP status code 403
alias../../../../../../../../../../../ => HTTP status code 400
alias../ => HTTP status code 403

Onveilige padbeperking

Kyk na die volgende bladsy om te leer hoe om riglyne soos te omseil:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Proxy / WAF Protections Bypass

Onveilige gebruik van veranderlikes / HTTP Versoek Splitsing

'n Kwetsbaarheid in Nginx-konfigurasie word gedemonstreer deur die voorbeeld hieronder:

location / {
return 302 https://example.com$uri;
}

Die karakters \r (Carriage Return) en \n (Line Feed) dui nuwe lyn karakters in HTTP versoeke aan, en hul URL-gecodeerde vorms word voorgestel as %0d%0a. Om hierdie karakters in 'n versoek in te sluit (bv. http://localhost/%0d%0aDetectify:%20clrf) na 'n verkeerd geconfigureerde bediener lei tot die bediener wat 'n nuwe kop genaamd Detectify uitreik. Dit gebeur omdat die $uri veranderlike die URL-gecodeerde nuwe lyn karakters decodeer, wat lei tot 'n onverwagte kop in die antwoord:

HTTP/1.1 302 Moved Temporarily
Server: nginx/1.19.3
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
Location: https://example.com/
Detectify: clrf

Leer meer oor die risiko's van CRLF-inspuiting en respons-splitting by https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

Ook hierdie tegniek is verduidelik in hierdie praatjie met 'n paar kwesbare voorbeelde en opsporingsmeganismes. Byvoorbeeld, om hierdie miskonfigurasie vanuit 'n swartdoos perspektief op te spoor, kan jy hierdie versoeke gebruik:

• https://example.com/%20X - Enige HTTP-kode
• https://example.com/%20H - 400 Bad Request

As dit kwesbaar is, sal die eerste terugkeer as "X" is enige HTTP-metode en die tweede sal 'n fout teruggee aangesien H nie 'n geldige metode is nie. So die bediener sal iets soos ontvang: GET / H HTTP/1.1 en dit sal die fout aktiveer.

Nog 'n opsporingsvoorbeeld sou wees:

• http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - Enige HTTP-kode
• http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Bad Request

Sommige kwesbare konfigurasies wat in daardie praatjie gevind is, was:

• Let op hoe $uri soos dit is in die finale URL gestel is.

location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}

• Let op hoe weer $uri in die URL is (denke keer binne 'n parameter)

location ~ ^/dna/payment {
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
proxy_pass http://$back;

• Nou in AWS S3

location /s3/ {
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
}

Enige veranderlike

Daar is ontdek dat gebruikersgeleverde data as 'n Nginx veranderlike onder sekere omstandighede behandel kan word. Die oorsaak van hierdie gedrag bly ietwat ontwykend, maar dit is nie ongewoon of eenvoudig om te verifieer nie. Hierdie anomalie is in 'n sekuriteitsverslag op HackerOne beklemtoon, wat hier beskou kan word. Verdere ondersoek na die foutboodskap het gelei tot die identifikasie van sy voorkoms binne die SSI filtermodule van Nginx se kodebasis, wat Server Side Includes (SSI) as die worteloorsaak aandui.

Om hierdie miskonfigurasie te ontdek, kan die volgende opdrag uitgevoer word, wat behels om 'n referer-kop te stel om vir veranderlike druk te toets:

$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’

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;
}

In ons konfigurasie het ons die riglyn try_files wat gebruik word om die bestaan van lêers in 'n gespesifiseerde volgorde te kontroleer. Nginx sal die eerste een bedien wat dit sal vind. Die basiese sintaksis van die try_files riglyn is soos volg:

try_files file1 file2 ... fileN fallback;

Nginx sal die bestaan van elke lêer in die gespesifiseerde volgorde nagaan. As 'n lêer bestaan, sal dit onmiddellik bedien word. As geen van die gespesifiseerde lêers bestaan nie, sal die versoek aan die terugvalopsie oorgedra word, wat 'n ander URI of 'n spesifieke foutbladsy kan wees.

E however, wanneer $uri$args veranderlikes in hierdie riglyn gebruik word, sal die Nginx probeer om 'n lêer te soek wat ooreenstem met die versoek URI gekombineer met enige navraagstring argumente. Daarom kan ons hierdie konfigurasie benut:

http {
server {
root /var/www/html/public;

location / {
try_files $uri$args $uri$args/ /index.html;
}
}
}

Met die volgende payload:

GET /?../../../../../../../../etc/passwd HTTP/1.1
Host: example.com

Met ons payload sal ons die wortelgids (gedefinieer in die Nginx-konfigurasie) ontsnap en die /etc/passwd-lêer laai. In debug logs kan ons sien hoe die Nginx die lêers probeer:

...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 teen Nginx met die konfigurasie hierbo genoem:

Rauwe backend antwoord lees

Nginx bied 'n funksie deur proxy_pass wat die onderskepping van foute en HTTP koptekste wat deur die backend geproduseer word, toelaat, met die doel om interne foutboodskappe en koptekste te verberg. Dit word bereik deurdat Nginx pasgemaakte foutbladsye dien in reaksie op backend foute. egter, uitdagings ontstaan wanneer Nginx 'n ongeldige HTTP versoek teëkom. So 'n versoek word na die backend gestuur soos ontvang, en die backend se rauwe antwoord word dan direk aan die kliënt gestuur sonder Nginx se tussenkoms.

Oorweeg 'n voorbeeldscenario wat 'n uWSGI toepassing betrek:

def application(environ, start_response):
start_response('500 Error', [('Content-Type', 'text/html'), ('Secret-Header', 'secret-info')])
return [b"Secret info, should not be visible!"]

Om dit te bestuur, word spesifieke riglyne in die Nginx-konfigurasie gebruik:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}

• proxy_intercept_errors: Hierdie riglyn stel Nginx in staat om 'n pasgemaakte antwoord te dien vir agtergrond-antwoorde met 'n statuskode groter as 300. Dit verseker dat, vir ons voorbeeld uWSGI-toepassing, 'n 500 Error antwoord onderskep en hanteer word deur Nginx.
• proxy_hide_header: Soos die naam aandui, verberg hierdie riglyn gespesifiseerde HTTP-koptekste van die kliënt, wat privaatheid en sekuriteit verbeter.

Wanneer 'n geldige GET versoek gemaak word, verwerk Nginx dit normaalweg, en keer 'n standaard foutantwoord terug sonder om enige geheime koptekste te onthul. 'n Ongeldige HTTP-versoek omseil egter hierdie meganisme, wat lei tot die blootstelling van rou agtergrond-antwoorde, insluitend geheime koptekste en foutboodskappe.

merge_slashes op af

Standaard is Nginx se merge_slashes riglyn op aan gestel, wat verskeie vorentoe-skuins in 'n URL in 'n enkele skuins saampers. Hierdie kenmerk, terwyl dit URL-verwerking stroomlyn, kan onbedoeld kwesbaarhede in toepassings agter Nginx verberg, veral dié wat geneig is tot plaaslike lêerinsluiting (LFI) aanvalle. Sekuriteitskenners Danny Robinson en Rotem Bar het die potensiële risiko's wat met hierdie standaardgedrag geassosieer word, beklemtoon, veral wanneer Nginx as 'n omgekeerde proxy optree.

Om sulke risiko's te verminder, word dit aanbeveel om die merge_slashes riglyn af te skakel vir toepassings wat vatbaar is vir hierdie kwesbaarhede. Dit verseker dat Nginx versoeke aan die toepassing deurgee sonder om die URL-struktuur te verander, en dus nie enige onderliggende sekuriteitskwessies te verberg nie.

Vir meer inligting, kyk na Danny Robinson en Rotem Bar.

Maclicious Response Headers

Soos getoon in hierdie skrywe, is daar sekere koptekste wat, indien teenwoordig in die antwoord van die webbediener, die gedrag van die Nginx-proxy sal verander. Jy kan hulle in die dokumentasie nagaan:

• X-Accel-Redirect: Dui aan Nginx om 'n versoek intern na 'n gespesifiseerde ligging te herlei.
• X-Accel-Buffering: Beheer of Nginx die antwoord moet buffere of nie.
• X-Accel-Charset: Stel die karakterstel vir die antwoord in wanneer X-Accel-Redirect gebruik word.
• X-Accel-Expires: Stel die vervaldatum vir die antwoord in wanneer X-Accel-Redirect gebruik word.
• X-Accel-Limit-Rate: Beperk die oordragtempo vir antwoorde wanneer X-Accel-Redirect gebruik word.

Byvoorbeeld, die koptekst X-Accel-Redirect sal 'n interne herleiding in die nginx veroorsaak. Dus, om 'n nginx-konfigurasie te hê met iets soos root / en 'n antwoord van die webbediener met X-Accel-Redirect: .env sal maak dat nginx die inhoud van /.env (Path Traversal) stuur.

Standaardwaarde in Map Riglyn

In die Nginx-konfigurasie speel die map riglyn dikwels 'n rol in autoriseringbeheer. 'n Algemene fout is om nie 'n standaard waarde te spesifiseer nie, wat kan lei tot ongeoorloofde toegang. Byvoorbeeld:

http {
map $uri $mappocallow {
/map-poc/private 0;
/map-poc/secret 0;
/map-poc/public 1;
}
}

server {
location /map-poc {
if ($mappocallow = 0) {return 403;}
return 200 "Hello. It is private area: $mappocallow";
}
}

Without a default, a malicious user kan sekuriteit omseil deur toegang te verkry tot 'n onbeskryfde URI binne /map-poc. Die Nginx handleiding adviseer om 'n default waarde in te stel om sulke probleme te vermy.

DNS Spoofing Kwetsbaarheid

DNS spoofing teen Nginx is haalbaar onder sekere omstandighede. As 'n aanvaller die DNS bediener wat deur Nginx gebruik word, ken en sy DNS-vrae kan onderskep, kan hulle DNS-rekords spoof. Hierdie metode is egter ondoeltreffend as Nginx geconfigureer is om localhost (127.0.0.1) vir DNS-resolusie te gebruik. Nginx laat toe om 'n DNS bediener soos volg te spesifiseer:

resolver 8.8.8.8;

proxy_pass en internal Direktiewe

Die proxy_pass direktief word gebruik om versoeke na ander bedieners te herlei, hetsy intern of ekstern. Die internal direktief verseker dat sekere plekke slegs binne Nginx toeganklik is. Alhoewel hierdie direktiewe nie kwesbaarhede op hul eie is nie, vereis hul konfigurasie noukeurige ondersoek om sekuriteitsfoute te voorkom.

proxy_set_header Upgrade & Connection

As die nginx bediener geconfigureer is om die Upgrade en Connection headers oor te dra, kan 'n h2c Smuggling aanval uitgevoer word om toegang tot beskermde/internale eindpunte te verkry.

Voorbeeld van kwesbare konfigurasie om /flag te steel van hier:

server {
listen       443 ssl;
server_name  localhost;

ssl_certificate       /usr/local/nginx/conf/cert.pem;
ssl_certificate_key   /usr/local/nginx/conf/privkey.pem;

location / {
proxy_pass http://backend:9999;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
}

location /flag {
deny all;
}

Probeer dit self

Detectify het 'n GitHub-repo geskep waar jy Docker kan gebruik om jou eie kwesbare Nginx-toetsbediener op te stel met 'n paar van die miskonfigurasies wat in hierdie artikel bespreek is en probeer om dit self te vind!

https://github.com/detectify/vulnerable-nginx

Statiese Analise gereedskap

GIXY

Gixy is 'n hulpmiddel om Nginx-konfigurasie te analiseer. Die hoofdoel van Gixy is om sekuriteitsmisconfigurasie te voorkom en foutdetectie te outomatiseer.

Nginxpwner

Nginxpwner is 'n eenvoudige hulpmiddel om te soek na algemene Nginx-miskonfigurasies en kwesbaarhede.

Verwysings

• https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/
• http://blog.zorinaq.com/nginx-resolver-vulns/
• https://github.com/yandex/gixy/issues/115