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

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

@@ -5,7 +5,7 @@
 
 ## Missing root location <a href="#missing-root-location" id="missing-root-location"></a>
 
-Wakati wa kusanidi seva ya Nginx, **root directive** ina jukumu muhimu kwa kufafanua saraka ya msingi ambayo faili zinatolewa. Fikiria mfano hapa chini:
+Wakati wa kusanidi seva ya Nginx, **root directive** ina jukumu muhimu kwa kufafanua saraka ya msingi ambayo faili zinatolewa. Fikiria mfano ufuatao:
 ```bash
 server {
 root /etc/nginx;
@@ -16,13 +16,13 @@ proxy_pass http://127.0.0.1:8080/;
 }
 }
 ```
-Katika usanidi huu, `/etc/nginx` imewekwa kama saraka ya mzizi. Mipangilio hii inaruhusu ufikiaji wa faili ndani ya saraka iliyoainishwa, kama vile `/hello.txt`. Hata hivyo, ni muhimu kutambua kwamba eneo maalum tu (`/hello.txt`) limeainishwa. Hakuna usanidi kwa eneo la mzizi (`location / {...}`). Kukosekana kwa hili kunamaanisha kwamba mwelekeo wa mzizi unatumika kwa ujumla, ukiruhusu maombi kwa njia ya mzizi `/` kufikia faili chini ya `/etc/nginx`.
+Katika usanidi huu, `/etc/nginx` imewekwa kama saraka ya mzizi. Usanidi huu unaruhusu ufikiaji wa faili ndani ya saraka iliyoainishwa ya mzizi, kama vile `/hello.txt`. Hata hivyo, ni muhimu kutambua kwamba eneo maalum tu (`/hello.txt`) limeainishwa. Hakuna usanidi wa eneo la mzizi (`location / {...}`). Kukosekana kwa hili kunamaanisha kwamba mwelekeo wa mzizi unatumika kwa ujumla, ukiruhusu maombi kwenye njia ya mzizi `/` kufikia faili chini ya `/etc/nginx`.
 
-Kipengele muhimu cha usalama kinatokea kutokana na usanidi huu. Ombi rahisi la `GET`, kama `GET /nginx.conf`, linaweza kufichua taarifa nyeti kwa kutumikia faili ya usanidi wa Nginx iliyoko kwenye `/etc/nginx/nginx.conf`. Kuweka mzizi kwenye saraka isiyo nyeti sana, kama `/etc`, kunaweza kupunguza hatari hii, lakini bado kunaweza kuruhusu ufikiaji usio kusudi wa faili nyingine muhimu, ikiwa ni pamoja na faili zingine za usanidi, kumbukumbu za ufikiaji, na hata akidi zilizofichwa zinazotumika kwa uthibitishaji wa msingi wa HTTP.
+Kipengele muhimu cha usalama kinatokea kutokana na usanidi huu. Ombi rahisi la `GET`, kama `GET /nginx.conf`, linaweza kufichua taarifa nyeti kwa kutoa faili ya usanidi wa Nginx iliyoko kwenye `/etc/nginx/nginx.conf`. Kuweka mzizi kwenye saraka isiyo nyeti sana, kama `/etc`, kunaweza kupunguza hatari hii, lakini bado kunaweza kuruhusu ufikiaji usio na makusudi wa faili nyingine muhimu, ikiwa ni pamoja na faili zingine za usanidi, kumbukumbu za ufikiaji, na hata akidi zilizofichwa zinazotumika kwa uthibitishaji wa msingi wa HTTP.
 
 ## Alias LFI Misconfiguration <a href="#alias-lfi-misconfiguration" id="alias-lfi-misconfiguration"></a>
 
-Katika faili za usanidi za Nginx, ukaguzi wa karibu unahitajika kwa mwelekeo wa "location". Uthibitisho wa udhaifu unaojulikana kama Local File Inclusion (LFI) unaweza kuanzishwa bila kukusudia kupitia usanidi unaofanana na ifuatayo:
+Katika faili za usanidi za Nginx, ukaguzi wa karibu unahitajika kwa mwelekeo wa "location". Uthibitisho unaojulikana kama Local File Inclusion (LFI) unaweza kuanzishwa bila kukusudia kupitia usanidi unaofanana na ifuatayo:
 ```
 location /imgs {
 alias /path/images/;
@@ -81,7 +81,7 @@ location / {
 return 302 https://example.com$uri;
 }
 ```
-Characters \r (Carriage Return) na \n (Line Feed) zinaashiria wahusika wapya katika maombi ya HTTP, na aina zao za URL-encoded zinawakilishwa kama `%0d%0a`. Kuongeza wahusika hawa katika ombi (kwa mfano, `http://localhost/%0d%0aDetectify:%20clrf`) kwa seva isiyo na usanidi mzuri kunasababisha seva kutoa kichwa kipya kinachoitwa `Detectify`. Hii inatokea kwa sababu ya $uri variable inayofungua wahusika wapya wa URL-encoded, na kusababisha kichwa kisichotarajiwa katika jibu:
+Makarakteri \r (Carriage Return) na \n (Line Feed) yanaashiria wahusika wapya katika maombi ya HTTP, na aina zao za URL-encoded zinawakilishwa kama `%0d%0a`. Kuongeza wahusika hawa katika ombi (kwa mfano, `http://localhost/%0d%0aDetectify:%20clrf`) kwa seva isiyo na usanidi mzuri kunasababisha seva kutoa kichwa kipya kinachoitwa `Detectify`. Hii inatokea kwa sababu ya $uri variable inayofungua wahusika wapya wa URL-encoded, na kusababisha kichwa kisichotarajiwa katika jibu:
 ```
 HTTP/1.1 302 Moved Temporarily
 Server: nginx/1.19.3
@@ -93,19 +93,19 @@ 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/](https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/).
 
-Pia, mbinu hii [**imeelezwa katika mazungumzo haya**](https://www.youtube.com/watch?v=gWQyWdZbdoY&list=PL0xCSYnG_iTtJe2V6PQqamBF73n7-f1Nr&index=77) ikiwa na mifano yenye udhaifu na mitambo ya kugundua. Kwa mfano, ili kugundua usanidi huu usio sahihi kutoka kwa mtazamo wa sanduku jeusi unaweza kutumia maombi haya:
+Pia, mbinu hii [**imeelezwa katika mazungumzo haya**](https://www.youtube.com/watch?v=gWQyWdZbdoY&list=PL0xCSYnG_iTtJe2V6PQqamBF73n7-f1Nr&index=77) ikiwa na mifano yenye udhaifu na mitambo ya kugundua. Kwa mfano, ili kugundua usanidi huu mbaya kutoka kwa mtazamo wa sanduku jeusi unaweza kutumia maombi haya:
 
 - `https://example.com/%20X` - Kila nambari ya HTTP
 - `https://example.com/%20H` - 400 Bad Request
 
-Ikiwa kuna udhaifu, ya kwanza itarudisha kama "X" ni njia yoyote ya HTTP na ya pili itarudisha kosa kwani H si njia halali. Hivyo, seva itapokea kitu kama: `GET / H HTTP/1.1` na hii itasababisha kosa.
+Ikiwa kuna udhaifu, ya kwanza itarudisha kama "X" ni njia yoyote ya HTTP na ya pili itarudisha kosa kwani H si njia halali. Hivyo, seva itapata kitu kama: `GET / H HTTP/1.1` na hii itasababisha kosa.
 
 Mifano mingine ya kugundua ingekuwa:
 
 - `http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x` - Kila nambari ya HTTP
 - `http://company.tld/%20HTTP/1.1%0D%0AHost:%20x` - 400 Bad Request
 
-Baadhi ya usanidi wenye udhaifu ulioonekana katika mazungumzo hayo ni:
+Baadhi ya usanidi wenye udhaifu ulioonekana katika mazungumzo hayo ulikuwa:
 
 - Kumbuka jinsi **`$uri`** ilivyowekwa kama ilivyo katika URL ya mwisho.
 ```
@@ -113,7 +113,7 @@ location ^~ /lite/api/ {
 proxy_pass http://lite-backend$uri$is_args$args;
 }
 ```
-- Kumbuka jinsi tena **`$uri`** iko katika URL (wakati huu ndani ya parameter)
+- Kumbuka jinsi tena **`$uri`** iko katika URL (hii mara hii ndani ya parameter)
 ```
 location ~ ^/dna/payment {
 rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
@@ -127,19 +127,69 @@ proxy_pass https://company-bucket.s3.amazonaws.com$uri;
 ```
 ### Any variable
 
-Iligundulika kwamba **data iliyotolewa na mtumiaji** inaweza kut treated kama **Nginx variable** chini ya hali fulani. Sababu ya tabia hii bado ni ngumu kidogo, lakini si nadra wala rahisi kuthibitisha. Anomali hii ilisisitizwa katika ripoti ya usalama kwenye HackerOne, ambayo inaweza kuonekana [here](https://hackerone.com/reports/370094). Uchunguzi zaidi wa ujumbe wa kosa ulisababisha kutambua kutokea kwake ndani ya [SSI filter module of Nginx's codebase](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365), ikitaja Server Side Includes (SSI) kama sababu kuu.
+Iligundulika kwamba **data inayotolewa na mtumiaji** inaweza kut treated kama **Nginx variable** chini ya hali fulani. Sababu ya tabia hii bado haijajulikana vizuri, lakini si nadra wala rahisi kuthibitisha. Anomali hii ilionyeshwa katika ripoti ya usalama kwenye HackerOne, ambayo inaweza kuonekana [here](https://hackerone.com/reports/370094). Uchunguzi zaidi wa ujumbe wa kosa ulisababisha kubaini kutokea kwake ndani ya [SSI filter module of Nginx's codebase](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365), ikitaja Server Side Includes (SSI) kama sababu ya msingi.
 
 Ili **kuona hii misconfiguration**, amri ifuatayo inaweza kutekelezwa, ambayo inahusisha kuweka kichwa cha referer ili kujaribu uchapishaji wa variable:
 ```bash
 $ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’
 ```
-Skana za usanidi huu mbaya katika mifumo zilionyesha matukio kadhaa ambapo mabadiliko ya Nginx yanaweza kuonyeshwa na mtumiaji. Hata hivyo, kupungua kwa idadi ya matukio yaliyo hatarini kunapendekeza kwamba juhudi za kurekebisha tatizo hili zimefanikiwa kwa kiasi fulani.
+Skana za usumbufu huu katika mifumo zilionyesha matukio kadhaa ambapo mabadiliko ya Nginx yanaweza kuchapishwa na mtumiaji. Hata hivyo, kupungua kwa idadi ya matukio yaliyo hatarini kunapendekeza kwamba juhudi za kurekebisha tatizo hili zimefanikiwa kwa kiasi fulani.
+
+### Kutumia try_files na $URI$ARGS mabadiliko
+
+Usumbufu ufuatao wa Nginx unaweza kusababisha udhaifu wa LFI:
+```
+location / {
+try_files $uri$args $uri$args/ /index.html;
+}
+```
+Katika usanidi wetu tunaelekezo `try_files` ambayo inatumika kuangalia uwepo wa faili kwa mpangilio ulioainishwa. Nginx itatoa ile ya kwanza ambayo itapata. Sintaksia ya msingi ya elekezo la `try_files` ni kama ifuatavyo:
+```
+try_files file1 file2 ... fileN fallback;
+```
+Nginx itakagua uwepo wa kila faili katika mpangilio ulioelezwa. Ikiwa faili ipo, itatolewa mara moja. Ikiwa hakuna faili yoyote iliyotajwa, ombi litapewa chaguo mbadala, ambacho kinaweza kuwa URI nyingine au ukurasa maalum wa makosa.
+
+Hata hivyo, wakati wa kutumia `$uri$args` variables katika mwelekeo huu, Nginx itajaribu kutafuta faili inayolingana na URI ya ombi iliyounganishwa na hoja zozote za muktadha. Hivyo tunaweza kutumia 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 tutakimbia kwenye saraka ya mzizi (iliyofafanuliwa katika usanidi wa Nginx) na kupakia faili ya `/etc/passwd`. Katika kumbukumbu za debug tunaweza kuona jinsi Nginx inavyofanya kazi na 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 kutumia usanidi ulioelezwa hapo juu:
+![Example burp request](../../images/nginx_try_files.png)
 
 ## Kusoma majibu ya nyuma ya raw
 
-Nginx inatoa kipengele kupitia `proxy_pass` ambacho kinaruhusu kukamatwa kwa makosa na vichwa vya HTTP vinavyotolewa na backend, kwa lengo la kuficha ujumbe wa makosa ya ndani na vichwa. Hii inafanywa kwa Nginx kutoa kurasa za makosa za kawaida kama majibu kwa makosa ya backend. Hata hivyo, changamoto zinatokea wakati Nginx inakutana na ombi la HTTP lisilo sahihi. Ombi kama hilo linapelekwa kwa backend kama lilivyo, na jibu la raw la backend kisha linatumwa moja kwa moja kwa mteja bila kuingilia kati kwa Nginx.
+Nginx inatoa kipengele kupitia `proxy_pass` ambacho kinaruhusu kukamatwa kwa makosa na vichwa vya HTTP vinavyotolewa na backend, kwa lengo la kuficha ujumbe wa makosa ya ndani na vichwa. Hii inafanywa kwa Nginx kuhudumia kurasa za makosa za kawaida kama majibu kwa makosa ya backend. Hata hivyo, changamoto zinatokea wakati Nginx inakutana na ombi la HTTP lisilo sahihi. Ombi kama hilo linapelekwa kwa backend kama lilivyo, na jibu la raw la backend kisha linatumwa moja kwa moja kwa mteja bila kuingilia kati kwa Nginx.
 
-Fikiria mfano wa hali inayohusisha programu ya uWSGI:
+Fikiria mfano wa hali unaohusisha programu ya uWSGI:
 ```python
 def application(environ, start_response):
 start_response('500 Error', [('Content-Type', 'text/html'), ('Secret-Header', 'secret-info')])
@@ -156,19 +206,19 @@ proxy_hide_header Secret-Header;
 - [**proxy_intercept_errors**](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_intercept_errors): Hii amri inaruhusu Nginx kutoa jibu maalum kwa majibu ya nyuma yenye msimbo wa hali zaidi ya 300. Inahakikisha kwamba, kwa mfano wetu wa programu ya uWSGI, jibu la `500 Error` linakamatwa na kushughulikiwa na Nginx.
 - [**proxy_hide_header**](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_hide_header): Kama jina linavyopendekeza, hii amri inaficha vichwa vya HTTP vilivyotajwa kutoka kwa mteja, ikiongeza faragha na usalama.
 
-Wakati ombi halali la `GET` linapotolewa, Nginx linafanya kazi yake kawaida, likirejesha jibu la makosa la kawaida bila kufichua vichwa vya siri. Hata hivyo, ombi la HTTP lisilo sahihi linapita mfumo huu, na kusababisha kufichuliwa kwa majibu ya nyuma ya asili, ikiwa ni pamoja na vichwa vya siri na ujumbe wa makosa.
+Wakati ombi halali la `GET` linapotolewa, Nginx linafanya kazi yake kawaida, likirejesha jibu la makosa la kawaida bila kufichua vichwa vya siri. Hata hivyo, ombi la HTTP lisilo sahihi linapita mfumo huu, na kusababisha kufichuliwa kwa majibu ya nyuma ya kawaida, ikiwa ni pamoja na vichwa vya siri na ujumbe wa makosa.
 
 ## merge_slashes set to off
 
-Kwa kawaida, amri ya **`merge_slashes`** ya Nginx imewekwa kuwa **`on`**, ambayo inakusanya slashi nyingi za mbele katika URL kuwa slashi moja. Kipengele hiki, ingawa kinaboresha usindikaji wa URL, kinaweza kwa bahati mbaya kuficha udhaifu katika programu zilizo nyuma ya Nginx, hasa zile zinazoweza kukabiliwa na mashambulizi ya kuingiza faili za ndani (LFI). Wataalamu wa usalama **Danny Robinson na Rotem Bar** wameonyesha hatari zinazoweza kutokea zinazohusiana na tabia hii ya kawaida, hasa wakati Nginx inafanya kazi kama reverse-proxy.
+Kwa kawaida, amri ya **`merge_slashes`** ya Nginx imewekwa kuwa **`on`**, ambayo inakusanya slashi nyingi za mbele katika URL kuwa slashi moja. Kipengele hiki, ingawa kinaboresha usindikaji wa URL, kinaweza kwa bahati mbaya kuficha udhaifu katika programu zilizo nyuma ya Nginx, hasa zile zinazoweza kushambuliwa kwa mashambulizi ya kuingiza faili za ndani (LFI). Wataalamu wa usalama **Danny Robinson na Rotem Bar** wameonyesha hatari zinazoweza kutokea kutokana na tabia hii ya kawaida, hasa wakati Nginx inafanya kazi kama reverse-proxy.
 
-Ili kupunguza hatari kama hizo, inapendekezwa **kugeuza amri ya `merge_slashes` kuwa off** kwa programu zinazoweza kukabiliwa na udhaifu hizi. Hii inahakikisha kwamba Nginx inapeleka maombi kwa programu bila kubadilisha muundo wa URL, hivyo basi haitaweza kuficha matatizo yoyote ya usalama yaliyofichika.
+Ili kupunguza hatari kama hizo, inapendekezwa **kugeuza amri ya `merge_slashes` kuwa off** kwa programu zinazoweza kuathiriwa na udhaifu hizi. Hii inahakikisha kwamba Nginx inapeleka maombi kwa programu bila kubadilisha muundo wa URL, hivyo basi haitaweza kuficha matatizo yoyote ya usalama yaliyofichika.
 
 Kwa maelezo zaidi angalia [Danny Robinson na Rotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d).
 
 ### **Maclicious Response Headers**
 
-Kama inavyoonyeshwa katika [**hii andiko**](https://mizu.re/post/cors-playground), kuna vichwa fulani ambavyo ikiwa vipo katika jibu kutoka kwa seva ya wavuti vitabadilisha tabia ya proxy ya Nginx. Unaweza kuangalia katika [**nyaraka**](https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/):
+Kama inavyoonyeshwa katika [**hii andiko**](https://mizu.re/post/cors-playground), kuna vichwa fulani ambavyo ikiwa vipo katika jibu kutoka kwa seva ya wavuti vitabadilisha tabia ya proxy ya Nginx. Unaweza kuangalia [**katika nyaraka**](https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/):
 
 - `X-Accel-Redirect`: Inaonyesha Nginx kuhamasisha ombi kwa eneo lililotajwa.
 - `X-Accel-Buffering`: Inadhibiti ikiwa Nginx inapaswa kubuffer jibu au la.
@@ -180,7 +230,7 @@ Kwa mfano, kichwa **`X-Accel-Redirect`** kitasababisha **redirect** ya ndani kat
 
 ### **Default Value in Map Directive**
 
-Katika **usanidi wa Nginx**, amri ya `map` mara nyingi ina jukumu katika **udhibiti wa mamlaka**. Kosa la kawaida ni kutoshughulikia **thamani ya default**, ambayo inaweza kusababisha ufikiaji usioidhinishwa. Kwa mfano:
+Katika **usanidi wa Nginx**, amri ya `map` mara nyingi ina jukumu katika **udhibiti wa idhini**. Kosa la kawaida ni kutoshiriki **thamani ya default**, ambayo inaweza kusababisha ufikiaji usioidhinishwa. Kwa mfano:
 ```yaml
 http {
 map $uri $mappocallow {
@@ -201,9 +251,9 @@ return 200 "Hello. It is private area: $mappocallow";
 ```
 Bila `default`, **mtumiaji mbaya** anaweza kupita usalama kwa kufikia **URI isiyofafanuliwa** ndani ya `/map-poc`. [Mwongozo wa Nginx](https://nginx.org/en/docs/http/ngx_http_map_module.html) unashauri kuweka **thamani ya default** ili kuepuka matatizo kama haya.
 
-### **Udhaifu wa DNS Spoofing**
+### **Uhatari wa DNS Spoofing**
 
-DNS spoofing dhidi ya Nginx inawezekana chini ya hali fulani. Ikiwa mshambuliaji anajua **seva ya DNS** inayotumika na Nginx na anaweza kukamata maswali yake ya DNS, wanaweza kudanganya rekodi za DNS. Hata hivyo, njia hii haiwezi kufanya kazi ikiwa Nginx imewekwa kutumia **localhost (127.0.0.1)** kwa ajili ya ufumbuzi wa DNS. Nginx inaruhusu kuweka seva ya DNS kama ifuatavyo:
+DNS spoofing dhidi ya Nginx inawezekana chini ya hali fulani. Ikiwa mshambuliaji anajua **seva ya DNS** inayotumiwa na Nginx na anaweza kukamata maswali yake ya DNS, wanaweza kudanganya rekodi za DNS. Hata hivyo, njia hii haiwezi kufanya kazi ikiwa Nginx imewekwa kutumia **localhost (127.0.0.1)** kwa ajili ya ufumbuzi wa DNS. Nginx inaruhusu kuweka seva ya DNS kama ifuatavyo:
 ```yaml
 resolver 8.8.8.8;
 ```
@@ -213,7 +263,7 @@ Miongozo ya **`proxy_pass`** inatumika kwa ajili ya kuelekeza maombi kwa seva ny
 
 ## proxy_set_header Upgrade & Connection
 
-Ikiwa seva ya nginx imewekwa ili kupitisha vichwa vya Upgrade na Connection, [**shambulio la h2c Smuggling**](../../pentesting-web/h2c-smuggling.md) linaweza kufanywa ili kufikia mwisho wa ndani/uliolindwa.
+Ikiwa seva ya nginx imewekwa ili kupitisha vichwa vya Upgrade na Connection, [**shambulio la h2c Smuggling**](../../pentesting-web/h2c-smuggling.md) linaweza kufanywa ili kufikia mwisho wa ndani/ulindwaji.
 
 > [!CAUTION]
 > Udhaifu huu utamruhusu mshambuliaji **kuanzisha muunganisho wa moja kwa moja na mwisho wa `proxy_pass`** (`http://backend:9999` katika kesi hii) ambao maudhui yake hayataangaliwa na nginx.
@@ -243,11 +293,11 @@ deny all;
 
 ## Jaribu mwenyewe
 
-Detectify imeunda hazina ya GitHub ambapo unaweza kutumia Docker kuanzisha seva yako ya mtihani ya Nginx iliyo na baadhi ya makosa ya usanidi yaliyajadiliwa katika makala hii na jaribu kuyapata mwenyewe!
+Detectify imeunda hazina ya GitHub ambapo unaweza kutumia Docker kuanzisha seva yako ya mtihani ya Nginx yenye udhaifu kadhaa zilizozungumziwa katika makala hii na jaribu kuzitafuta mwenyewe!
 
 [https://github.com/detectify/vulnerable-nginx](https://github.com/detectify/vulnerable-nginx)
 
-## Zana za Mchambuzi wa Kihistoria
+## Zana za Mchambuzi wa Kihandisi
 
 ### [GIXY](https://github.com/yandex/gixy)