Nginx

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Ukosefu wa root location

Wakati wa kusanidi seva ya Nginx, root directive ina jukumu muhimu kwa kufafanua saraka ya msingi kutoka ambayo faili hutolewa. Angalia mfano hapa chini:

server {
root /etc/nginx;

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

Katika usanidi huu, /etc/nginx imewekwa kama saraka ya root. Mpangilio huu unawezesha ufikaji wa faili ndani ya saraka ya root iliyobainishwa, kama /hello.txt. Hata hivyo, ni muhimu kutambua kwamba eneo maalum pekee (/hello.txt) limefafanuliwa. Hakuna usanidi kwa eneo la root (location / {...}). Upungufu huu unamaanisha kuwa directive ya root inatumika kwa ujumla, ikiruhusu maombi kwa njia ya root / kufikia faili chini ya /etc/nginx.

Jambo muhimu la usalama linatokana na usanidi huu. Ombi rahisi la GET, kama GET /nginx.conf, linaweza kufichua taarifa nyeti kwa kuwa linahudumia faili la usanidi la Nginx lililoko katika /etc/nginx/nginx.conf. Kuweka root kwenye saraka isiyo nyeti zaidi, kama /etc, kunaweza kupunguza hatari hii, lakini bado kunaweza kuruhusu ufikaji usioakusudiwa kwa faili nyingine muhimu, ikiwa ni pamoja na faili nyingine za usanidi, access logs, na hata encrypted credentials zinazotumiwa kwa HTTP basic authentication.

Alias LFI Misconfiguration

Katika faili za usanidi za Nginx, uchunguzi wa karibu unahitajika kwa maelekezo ya “location”. Udhaifu unaojulikana kama Local File Inclusion (LFI) unaweza kuletwa bila kukusudi kupitia usanidi unaofanana na ufuatao:

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

Usanidi huu unaweka hatari ya mashambulizi ya LFI kwa sababu seva inatafsiri maombi kama /imgs../flag.txt kama jaribio la kufikia faili nje ya saraka iliyokusudiwa, kwa ufanisi ikitafsiriwa kuwa /path/images/../flag.txt. Hitilafu hii inaruhusu washambuliaji kupata faili kutoka kwenye filesystem ya seva ambazo hazipaswi kupatikana kupitia wavuti.

Ili kupunguza udhaifu huu, usanidi unapaswa kubadilishwa ili:

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

I don’t have the content of src/network-services-pentesting/pentesting-web/nginx.md — you only provided a link and “Accunetix tests:”. Please paste the markdown text you want translated (or confirm which exact sections to translate).

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

Kizuizi cha njia zisizo salama

Angalia ukurasa ufuatao ili kujifunza jinsi ya kuzunguka maagizo kama:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Proxy / WAF Protections Bypass

Matumizi hatari ya vigezo / HTTP Request Splitting

Caution

Vigezo vinavyoharibika $uri na $document_uri na hili linaweza kurekebishwa kwa kubadilisha kwa $request_uri.

Regex pia inaweza kuwa hatarishi kama ifuatavyo:

location ~ /docs/([^/])? { … $1 … } - Hatarishi

location ~ /docs/([^/\s])? { … $1 … } - Sio hatarishi (kuangalia nafasi)

location ~ /docs/(.*)? { … $1 … } - Sio hatarishi

Udhaifu katika usanidi wa Nginx unaonyeshwa na mfano hapa chini:

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

Tabu \r (Carriage Return) na \n (Line Feed) zinaashiria kuanzisha mstari mpya katika maombi ya HTTP, na fomu zao zilizotangazwa kwa URL zinawakilishwa kama %0d%0a. Kujumuisha wahusika hawa katika ombi (mfano, http://localhost/%0d%0aDetectify:%20clrf) kwa server isiyopangwa ipasavyo husababisha server kutoa header mpya iitwayo Detectify. Hii hutokea kwa sababu variable $uri ina-decoding wahusika wa mstari mpya waliyo-URL-encoded, na kusababisha header isiyotarajiwa katika response:

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

Jifunze zaidi kuhusu hatari za CRLF injection na response splitting kwa https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

Pia tekniki hii ime explained in this talk pamoja na baadhi ya mifano yenye udhaifu na mbinu za kugundua. Kwa mfano, ili kugundua misconfiguration hii kutoka mtazamo wa blackbox unaweza kutuma maombi yafuatayo:

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

Ikiwa kuna udhaifu, ya kwanza itarudisha kwa sababu “X” ni method yoyote ya HTTP na ya pili itarudisha kosa kwa sababu H si method halali. Kwa hivyo server itapokea kitu kama: GET / H HTTP/1.1 na hii itasababisha kosa.

Mifano mingine ya kugundua itakuwa:

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

Baadhi ya mipangilio iliyoonekana kuwa dhaifu iliyowasilishwa katika hotuba hiyo ilikuwa:

  • Angalia jinsi $uri inavyowekwa kama ilivyo katika URL ya mwisho
location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}
  • Angalia tena jinsi $uri ilivyo katika URL (mara hii ndani ya kigezo)
location ~ ^/dna/payment {
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
proxy_pass http://$back;
  • Sasa kwenye AWS S3
location /s3/ {
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
}

Kigezo chochote

Iligundulika kuwa data inayotolewa na mtumiaji inaweza kutendewa kama kigezo cha Nginx chini ya mazingira fulani. Sababu ya tabia hii bado haijulikani kabisa, lakini si nadra wala si rahisi kuthibitisha. Anomali hii ilibainishwa katika ripoti ya usalama kwenye HackerOne, ambayo inaweza kuangaliwa here. Uchunguzi zaidi wa ujumbe wa kosa ulisababisha kubainika kwamba hutokea ndani ya SSI filter module of Nginx’s codebase, ikibainisha Server Side Includes (SSI) kuwa chanzo chake.

Ili kutambua usanidi huu usio sahihi, amri ifuatayo inaweza kutekelezwa, ambayo inahusisha kuweka referer header ili kujaribu uchapishaji wa kigezo:

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

Skani za kusanidi vibaya hili kwenye mifumo ziligundua matukio kadhaa ambapo vigezo vya Nginx vingeweza kuonyeshwa kwa mtumiaji. Hata hivyo, kupungua kwa idadi ya matukio yaliyo dhaifu kunaonyesha kwamba juhudi za kurekebisha tatizo hili zimefanikiwa kwa kiasi.

Kutumia try_files na vigezo vya $URI$ARGS

Kusanidi vibaya kwa Nginx kama ifuatavyo kunaweza kusababisha udhaifu wa LFI:

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

Katika usanidi wetu tuna directive try_files ambayo inatumiwa kuangalia uwepo wa faili kwa mpangilio ulioainishwa. Nginx itahudumia ile ya kwanza itakayopatikana. Sintaksi ya msingi ya directive try_files ifuatayo:

try_files file1 file2 ... fileN fallback;

Nginx itatafuta uwepo wa kila faili kwa mpangilio uliobainishwa. Ikiwa faili ipo, itatolewa mara moja. Ikiwa hakuna kati ya faili zilizotajwa, ombi litapelekwa kwa chaguo la fallback, ambalo linaweza kuwa URI nyingine au ukurasa maalum wa kosa.

Hata hivyo, wakati wa kutumia $uri$args vigezo katika maelekezo haya, Nginx itajaribu kutafuta faili inayolingana na URI ya ombi iliyounganishwa na chochote cha query string arguments. Kwa hivyo tunaweza ku-exploit usanidi huu:

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

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

Kwa payload ifuatayo:

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

Kwa kutumia payload yetu tutatoka kwenye root directory (iliyobainishwa kwenye usanidi wa Nginx) na kupakia faili ya /etc/passwd. Katika debug logs tunaweza kuona jinsi Nginx anavyojaribu faili hizo:

...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 dhidi ya Nginx ikitumia usanidi uliotajwa hapo juu: Mfano ombi la burp

Kusoma majibu ghafi ya backend

Nginx inatoa kipengele kupitia proxy_pass kinachowawezesha kukamata makosa na HTTP headers yanayotolewa na backend, kwa lengo la kuficha ujumbe wa ndani wa makosa na headers. Hii inatimizwa kwa Nginx kutoa kurasa za makosa maalum kama majibu kwa makosa ya backend. Hata hivyo, changamoto zinaibuka wakati Nginx inakutana na ombi la HTTP lisilo halali. Ombi kama hilo hutumwa kwa backend kama lilivyo, na majibu ghafi ya backend kisha hutumwa moja kwa moja kwa mteja bila uingiliaji wa Nginx.

Fikiria mfano unaohusisha application ya uWSGI:

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!"]

Ili kudhibiti hili, maelekezo maalum katika usanidi wa Nginx zinatumika:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}
  • proxy_intercept_errors: Directive hii inaruhusu Nginx kutoa jibu maalum kwa majibu ya backend yenye namba ya hali (status code) kubwa kuliko 300. Hii inahakikisha kwamba, kwa mfano wetu wa application uWSGI, jibu la 500 Error linakamatwa na kushughulikiwa na Nginx.
  • proxy_hide_header: Kama jina linavyosema, directive hii inaficha vichwa maalum vya HTTP kutoka kwa mteja, ikiongeza faragha na usalama.

Wakati ombi halali la GET linapotumwa, Nginx linalishughulikia kwa kawaida, likirejesha jibu la kosa la kawaida bila kufichua vichwa vya siri. Hata hivyo, ombi la HTTP lisilo halali linaepuka utaratibu huu, na kusababisha kufichuka kwa majibu ghafi kutoka backend, ikiwa ni pamoja na vichwa vya siri na ujumbe za makosa.

merge_slashes imewekwa kuwa off

Kwa chaguo-msingi, directive ya Nginx merge_slashes imewekwa kuwa on, ambayo inasukuma slashi nyingi katika URL kuwa slashi moja. Kipengele hiki, wakati kinaboresha usindikaji wa URL, kinaweza bila kukusudia kuficha udhaifu katika programu nyuma ya Nginx, hasa zile zilizo hatarini kwa local file inclusion (LFI) attacks. Wachanganuzi wa usalama Danny Robinson and Rotem Bar wametoa onyo kuhusu hatari zinazoweza kutokana na tabia hii ya default, hasa pale Nginx inapotumika kama reverse-proxy.

Ili kupunguza hatari hizi, inapendekezwa kuzima directive merge_slashes kwa programu zinazoweza kuathiriwa na udhaifu hizi. Hii inahakikisha kuwa Nginx inapitisha maombi kwa programu bila kubadilisha muundo wa URL, kwa hivyo haishemi matatizo ya usalama yaliyofichwa.

Kwa maelezo zaidi angalia Danny Robinson and Rotem Bar.

Vichwa vya Majibu Vinavyoweza Kuathiri

Kama ilivyoonyeshwa katika this writeup, kuna vichwa maalum ambavyo, ikiwa vipo katika jibu kutoka kwa web server, vitabadilisha tabia ya proxy ya Nginx. Unaweza kuangalia in the docs:

  • X-Accel-Redirect: Inaonyesha Nginx kufanya internal redirect ya ombi hadi eneo lililobainishwa.
  • X-Accel-Buffering: Inasimamia kama Nginx inapaswa ku-buffer jibu au la.
  • X-Accel-Charset: Inaweka character set kwa jibu wakati wa kutumia X-Accel-Redirect.
  • X-Accel-Expires: Inaweka muda wa kumalizika kwa jibu wakati wa kutumia X-Accel-Redirect.
  • X-Accel-Limit-Rate: Inapunguza kiwango cha uhamishaji kwa majibu wakati wa kutumia X-Accel-Redirect.

Kwa mfano, header X-Accel-Redirect itasababisha internal redirect katika nginx. Kwa hivyo kuwa na configuration ya nginx yenye kitu kama root / na jibu kutoka kwa web server lenye X-Accel-Redirect: .env kuta menyebabkan nginx itume yaliyomo ya /.env (Path Traversal).

Thamani ya Chaguo-msingi katika Directive ya map

Katika Nginx configuration, directive ya map mara nyingi ina jukumu katika authorization control. Makosa ya kawaida ni kutofafanua thamani ya default, ambayo inaweza kusababisha upatikanaji usioidhinishwa. Kwa mfano:

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

Pasipo default, mtumiaji mwenye nia mbaya anaweza kupita usalama kwa kufikia URI isiyotamuliwa ndani ya /map-poc. The Nginx manual inashauri kuweka thamani ya chaguo-msingi ili kuepuka matatizo hayo.

DNS Spoofing Udhaifu

DNS spoofing dhidi ya Nginx inawezekana chini ya masharti fulani. Ikiwa mshambuliaji anajua DNS server inayotumika na Nginx na anaweza kukamata DNS queries zake, anaweza kuiga DNS records. Hata hivyo, njia hii haitafaa ikiwa Nginx imewekwa kutumia localhost (127.0.0.1) kwa ajili ya kutatua DNS. Nginx inaruhusu kubainisha DNS server kama ifuatavyo:

resolver 8.8.8.8;

proxy_pass na internal Maelekezo

Maelekezo ya proxy_pass yanatumiwa kupeleka requests kwa server nyingine, ndani au nje. Maelekezo ya internal yana hakikisha kwamba maeneo fulani yanapatikana tu ndani ya Nginx. Ingawa maelekezo haya si udhaifu peke yao, usanidi wake unahitaji ukaguzi wa makini ili kuzuia mapungufu ya usalama.

proxy_set_header Upgrade & Connection

Iwapo server ya nginx imewekwa kupitisha header za Upgrade na Connection, h2c Smuggling attack inaweza kufanywa ili kupata ufikiaji wa endpoints zilizolindwa/za ndani.

Caution

Udhaifu huu ungeweza kumruhusu mshambuliaji kuanzisha muunganisho wa moja kwa moja na proxy_pass endpoint (http://backend:9999 katika kesi hii) ambapo yaliyomo hayatahakikiwa na nginx.

Mfano wa usanidi wenye udhaifu wa kuiba /flag kutoka here:

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

Warning

Kumbuka kwamba hata kama proxy_pass ilikuwa ikielekeza kwa path maalum kama http://backend:9999/socket.io muunganisho utaanzishwa na http://backend:9999 hivyo unaweza kuwasiliana na path yoyote nyingine ndani ya endpoint hiyo ya ndani. Kwa hiyo haijalishi kama path imeainishwa kwenye URL ya proxy_pass.

DoS ya mbali na leak ya module ya HTTP/3 QUIC (2024)

Mwaka 2024 Nginx ilitangaza CVE-2024-31079, CVE-2024-32760, CVE-2024-34161 na CVE-2024-35200, ikionyesha kwamba single hostile QUIC session inaweza crash worker processes au leak memory kila mara ngx_http_v3_module ya majaribio ikiwa imekompilishwa na socket ya listen ... quic iko wazi. Builds zilizoathirika ni 1.25.0–1.25.5 na 1.26.0, wakati 1.27.0/1.26.1 zinaleta fixes; memory disclosure (CVE-2024-34161) pia inahitaji MTUs kubwa kuliko 4096 bytes ili kuonyesha data nyeti (maelezo katika advisory ya nginx ya 2024 iliyoreferenced hapo chini).

Recon & exploitation hints

  • HTTP/3 ni opt-in, hivyo scan kwa ajili ya Alt-Svc: h3=":443" responses au brute-force UDP/443 QUIC handshakes; mara itakapo thibitishwa, fuzz the handshake na STREAM frames kwa custom quiche-client/nghttp3 payloads ili trigger worker crashes na force log leakage.
  • Quickly fingerprint target support with:
nginx -V 2>&1 | grep -i http_v3
rg -n "listen .*quic" /etc/nginx/

Kupitisha kuendelea kwa kikao cha TLS kwa uthibitisho wa cheti cha mteja (CVE-2025-23419)

Ushauri wa Februari 2025 ulibainisha kwamba nginx 1.11.4–1.27.3 iliyojengwa na OpenSSL inaruhusu kutumia tena kikao cha TLS 1.3 kutoka kwenye virtual host moja inayotegemea jina ndani ya nyingine, hivyo mteja aliyefikia makubaliano na host isiyo na cheti anaweza kurejea ticket/PSK ili kuingia kwenye vhost iliyo na ulinzi wa ssl_verify_client on; na kukwepa mTLS kabisa. Hitilafu huanzishwa kila wakati vhost nyingi zinaposhirikiana cache ya kikao cha TLS 1.3 na tickets (angalia advisory ya nginx ya 2025 iliyoainishwa hapa chini).

Mpango wa mshambuliaji

# 1. Create a TLS session on the public vhost and save the session ticket
openssl s_client -connect public.example.com:443 -sess_out ticket.pem

# 2. Replay that session ticket against the mTLS vhost before it expires
openssl s_client -connect admin.example.com:443 -sess_in ticket.pem -ign_eof

Ikiwa lengo linaloweza kuathiriwa, handshake ya pili inakamilika bila kuwasilisha client certificate, ikifichua maeneo yaliyo salama.

Nini cha kukagua

  • Mixed server_name blocks that share ssl_session_cache shared:SSL plus ssl_session_tickets on;.
  • Admin/API blocks that expect mTLS but inherit shared session cache/ticket settings from public hosts.
  • Automation that enables TLS 1.3 session resumption globally (e.g., Ansible roles) without considering vhost isolation.

Uvumilivu wa HTTP/2 Rapid Reset (tabia ya CVE-2023-44487)

Shambulio la HTTP/2 Rapid Reset (CVE-2023-44487) bado linaathiri nginx wakati waendeshaji wanapoinua keepalive_requests au http2_max_concurrent_streams zaidi ya mipangilio ya default: mshambuliaji hufungua muunganisho wa HTTP/2, kuufunika na maelfu ya streams, kisha mara moja hutuma fremu za RST_STREAM ili dari ya concurrency isifikie wakati CPU inaendelea kutumia rasilimali kwenye logic ya kufunga sessions. Mipangilio ya default ya nginx (128 concurrent streams, 1000 keepalive requests) inafanya ukubwa wa athari kuwa mdogo; kuinua mipaka hiyo “kwa kiasi kikubwa” kunafanya kuwa rahisi kuwakosesha workers rasilimali hata kutoka kwa client mmoja (ona maelezo ya F5 yaliyotajwa hapa chini).

Vidokezo vya utambuzi

# Highlight risky knobs
rg -n "http2_max_concurrent_streams" /etc/nginx/
rg -n "keepalive_requests" /etc/nginx/

Vihosti vinavyoonyesha thamani isiyo ya kawaida kwa directives hizo ni malengo mazuri: mteja mmoja wa HTTP/2 anaweza kurudia hatua za kuunda streams na kutuma ghafla RST_STREAM frames ili kuweka CPU ikifanya kazi kwa nguvu bila kuvunja kikomo cha concurrency.

Jaribu wewe mwenyewe

Detectify imeunda hazina ya GitHub ambapo unaweza kutumia Docker kuanzisha server yako ya majaribio ya Nginx yenye mipangilio mibaya iliyoelezewa katika makala hii na kujaribu kuzitafuta mwenyewe!

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

Zana za Static Analyzer

gixy-ng & Gixy-Next & GIXY

  • Gixy-Next (tawi lililosasishwa la GIXY) ni zana ya kuchambua usanidi wa Nginx, kwa lengo la kupata vulnerabilities, insecure directives, na mipangilio hatarishi. Pia inapata mipangilio inayoathiri utendaji, na hugundua fursa za hardening zilizokosewa, ikiruhusu utambuzi wa kasoro kwa njia ya automated.
  • gixy-ng (tawi linalotunzwa kwa ufanisi la GIXY) ni zana ya kuchambua usanidi wa Nginx, kwa lengo la kupata vulnerabilities, insecure directives, na mipangilio hatarishi. Pia inapata mipangilio inayoathiri utendaji, na hugundua fursa za hardening zilizokosewa, ikiruhusu utambuzi wa kasoro kwa njia ya automated.

Nginxpwner

Nginxpwner ni zana rahisi ya kutafuta misconfigurations ya kawaida ya Nginx na vulnerabilities.

Marejeo

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks